URL Encode: Text to Percent-Encoding

Read a percent-encoded string back as text →

How do you URL encode a string?

URL encoding replaces the characters a URL cannot carry as data. A percent-encoded octet is a triplet: a percent sign followed by the two hexadecimal digits of that byte's value.

1. Write the text as UTF-8 octets first. That order is what makes a character outside US-ASCII into more than one triplet.
2. Leave every unreserved character as it is: A-Z a-z 0-9 - . _ ~.
3. Replace every other octet with a percent sign and that octet's 2 hexadecimal digits.
4. Check the reserved characters. Each is safe where it delimits and needs a triplet where it is data.
5. Read the result back to confirm it. hello world becomes hello%20world.

Text to Percent-Encoding 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.

Every value below is the one the specification fixes, so a result that disagrees with a row here is a result to check. ASCII defines 128 characters, codes 0–127, using 7 bits; in practice each code is stored in one 8-bit byte with a leading 0.

Worked Example: "hello world" to Percent-Encoding

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

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. 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, decode the percent-encoded output back to text and compare it with what you started from.

Worked examples: text to percent-encoding

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

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

What Decides Which Characters Get Encoded?

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.

What if the value is already Base64?

Then it may not need a triplet at all. The URL-safe alphabet of RFC 4648 section 5 keeps the first 62 characters and swaps plus for minus (-) and slash for underscore (_), so the result passes through a URL or a file name unchanged.

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 - when percent-encoding is the right choice sets out which does what.

Text to Percent-Encoding 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.quote('hello world', safe='')

JavaScript: encodeURIComponent('hello world')

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

• for a picture rather than a string, get the data URI for an image.
• markup needs a different scheme - write text as HTML entities instead.
• to carry raw bytes through a text-only channel, encode a string as Base64.
• if the value arrived escaped as entities, recover the text behind a string of entities first.
• when the value is a data URI holding a picture, get the file back from a data URI.
• if the value is already Base64, read a Base64 string back as text first.

The rest of the family sits on the full set of text encoding tools.