URL Decode: Percent-Encoding to Text

Percent-encode a string for a URL →

How do you decode an encoded URL?

URL decoding reads those triplets back as the characters they stand for. Decoding reverses the triplets one byte at a time and then reads the resulting bytes as UTF-8, so two triplets can produce a single character.

1. Find each percent sign. It opens a triplet: the percent and the 2 hexadecimal digits after it.
2. Read those two digits as one byte, and leave every other character alone.
3. Collect the bytes in the order they appeared.
4. Read the run of bytes as UTF-8, which is why two triplets can give one character.
5. Check the result for a leftover %25. hello%20world becomes hello world.

Percent-Encoding to Text Conversion Table

The reserved characters are the general delimiters : / ? # [ ] @ and the sub-delimiters ! $ & ' ( ) * + , ; = . Each one is safe where it acts as a delimiter and must be percent-encoded where it is data. The unreserved set is the ASCII letters, the digits, hyphen (-), period (.), underscore (_) and tilde (~). These characters never need percent-encoding, and a normaliser decodes them if it finds them encoded. Read the row for the character you have: the Triplet column is what a URL carries in its place. ASCII codes 32–126 are printable characters; 0–31 and 127 are control characters (for example 10 = line feed, 13 = carriage return, 32 = space). That row is the one everybody meets first.

The same value in each encoding

These rows are shared with the other encoders, so a value written here is the value every page in the family writes.

Worked Example: hello%20world to Text

One character at a time, with the working written out. This is the same grid the converter shows when you turn on "show steps".

For characters outside US-ASCII, RFC 3986 says to write the text as UTF-8 octets first and then percent-encode every octet that is not in the unreserved set, which is why é becomes %C3%A9.

Read the grid a row at a time: h is 68 and is written h; e is 65 and is written e; l is 6C and is written l. A character that is already unreserved keeps itself, so most of a readable string passes through untouched and only the characters a URL would misread change at all.

é is U+00E9 and encodes as C3 A9 (2 bytes); € is U+20AC and encodes as E2 82 AC (3 bytes); 😀 is U+1F600 and encodes as F0 9F 98 80 (4 bytes). UTF-8 encodes each character in 1 to 4 bytes. Characters 0–127 use one byte identical to ASCII, so ASCII text is valid UTF-8. Those byte counts are what decide how many triplets a character takes, which is why one character can arrive as two triplets and still be one character when it is read back.

Check it in reverse

A percent-encoded octet is a triplet: a percent sign followed by the two hexadecimal digits of that byte's value. Read the triplets in the order they appear and the original text comes back whole, because an unreserved character was never changed and a triplet always spells exactly one byte. To verify the result by hand, percent-encode the decoded text again and compare it with what you started from.

Worked examples: percent-encoding to text

Each example gives the value first, then the working. Click a value to load it in the converter.

Every example above reverses exactly - write the same characters back as triplets.

What Changes the Decoded Result?

Is the character data or a delimiter?

That is the whole decision, and only you know it. A slash between path segments is a delimiter and stays; a slash inside a value is data and becomes %2F.

Has the value been through the encoder twice?

A percent sign is itself percent-encoded as %25, so a string that has been through the encoder twice shows %2520 where one space should be.

What case are the hexadecimal digits?

0b marks binary, 0o octal, 0x hexadecimal; a leading # marks a hex colour. Hexadecimal is not case-sensitive (FF = ff); iToolHub writes hex digits in uppercase.

Is this the encoding you need at all?

The three schemes protect different things and are not interchangeable. these encodings are not interchangeable - why a string can be encoded more than one way sets out which does what.

Percent-Encoding to Text in Code

Both standard libraries carry this conversion, so the one-liner below is the whole job. Check the result against the table above before you trust it in a pipeline.

Python: urllib.parse.unquote('hello%20world')

JavaScript: decodeURIComponent('hello%20world')

Common Mistakes

• Encoding a whole URL rather than one value. The delimiters go too, and the address stops being an address.
• Running the encoder twice. A percent sign is itself percent-encoded as %25, so a string that has been through the encoder twice shows %2520 where one space should be.
• Assuming the space is the only problem. Every character outside the unreserved set needs a triplet, and the reserved ones need one whenever they are data.

Frequently Asked Questions

Related Conversions

• entities are a different scheme - turn escaped markup back into readable text instead.
• when the decoded value is a data URI, preview what a Base64 image holds.
• if the decoded value is Base64, decode a Base64 value next.
• for a picture rather than a string, embed an image as Base64 in CSS.
• before the decoded text goes into a page, escape a value before it goes into a page.
• to carry the decoded bytes through a text-only channel, write bytes as Base64 text.

The rest of the family sits on the rest of the text encoding converters.