Developer Guide

URL Encoding and Reserved Characters: What to Escape and When

By ToolFlic Expert Team Updated 9 October 2026 981 words

A URL travels as plain text over systems that only reliably carry a small set of ASCII characters, so anything outside that set - spaces, accents, punctuation, emoji - must be rewritten as percent-encoding: a % followed by the hexadecimal value of each byte. The subtlety is that some characters are delimiters with structural meaning (? & = / #), so escaping them changes what the URL means. Encode too little and the request is malformed; encode the wrong things and you destroy its structure.

That is why the URL encoder offers distinct modes: Encode Text escapes everything a single value cannot carry, Encode Full URL preserves the structural characters and escapes the rest, and Decode reverses percent-escapes - all done in your browser. This guide explains the character classes, which mode to use where, and the double-encoding traps.

Reserved vs unreserved characters

RFC 3986 divides the ASCII set into a few buckets. Unreserved characters - letters, digits and - _ . ~ - never need escaping. Reserved characters - : / ? # [ ] @ ! $ & ' ( ) * + , ; = - are allowed but carry special meaning, so whether you escape one depends on where it appears: an & inside a parameter value must be escaped (or the parser thinks a new parameter started), but the & between parameters must not be.

Everything else - space, ", %, non-ASCII - is invalid in a raw URL and must be percent-encoded. Understanding that reserved characters are structural is the whole game.

Class	Characters	Rule
Unreserved	A-Z a-z 0-9 - _ . ~	Never encode; safe anywhere.
Reserved (gen-delims)	: / ? # [ ] @	Encode only inside a value, keep as structure between parts.
Reserved (sub-delims)	! $ & ' ( ) * + , ; =	Contextual; escape inside values.
Everything else	space " % < > \ { \| } ^ ` and non-ASCII	Always percent-encode.

The practical takeaway: escaping is position-dependent, which is exactly why "encode the whole URL" and "encode one value" are genuinely different operations, not the same thing twice.

Encoding a value vs encoding a whole URL

Use Encode Text when you are inserting a value into a query string or path segment: it escapes the reserved characters too, so a value like a&b survives as a%26b and the ampersand is not mistaken for a separator. This is the behaviour of JavaScript encodeURIComponent() - the right tool for parameter values.

Use Encode Full URL when you already have a complete URL and only want to fix the characters that are actually illegal, leaving : / ? & = # intact so the structure survives. Feeding a whole URL through Encode Text is a classic mistake: the https:// collapses into https%3A%2F%2F and stops being a link.

UTF-8 bytes, spaces and the + versus %20 trap

Percent-encoding operates on bytes, so a non-ASCII character is encoded as its UTF-8 bytes: the e-acute é becomes %C3%A9 (two bytes, two escapes), not one. Spaces are the perennial confusion: a literal space is %20 in a URL path or query, but the older application/x-www-form-urlencoded style writes a space as +. Both decode to a space on the server, yet only %20 is correct in general URL syntax.

Know which convention the receiver expects; a value that must not contain a real + sign is where %2B matters, because an unescaped plus may be read as a space.

The double-encoding trap

Encoding something that is already encoded is one of the most common bugs: run hello%20world through the encoder again and the percent sign itself becomes %25, giving hello%2520world, which decodes to the literal text hello%20world - not a space. The tell is a stray %25 appearing in a URL or in stored data.

The fix is discipline about layers: encode exactly once, at the boundary where a raw value enters a URL, and never re-encode something a previous step already escaped. When unsure, use Decode - if it visibly changes, the string was encoded; run it again and if it changes once more you had a double encoding.

A safe encode-or-decode workflow

Because it runs in the browser, you can paste a real value, pick the mode that matches its role (Encode Text for a parameter, Encode Full URL for a whole link), and copy the result. To inspect a mystery string, run Decode and see whether readable text appears - a quick way to diagnose over-encoding. The UTM builder applies the same escaping automatically when it assembles campaign links, and base64 solves a related but different problem: safely carrying arbitrary bytes, not URL-legalising them.

Frequently Asked Questions

What is the difference between Encode Text and Encode Full URL?

Encode Text escapes every character a single value cannot carry, including the reserved ones - use it for a query parameter or path segment. Encode Full URL keeps the structural characters like : / ? & = # so the URL stays a URL and only escapes the illegal parts. Using the wrong one either breaks structure or leaves unsafe characters.

Why does my encoded URL show %2520?

You double-encoded. The first pass turned a space into %20, and a second pass turned the % into %25, producing %2520. Encode a value exactly once at the point it enters the URL and never re-encode something already escaped.

Should a space be %20 or a plus?

In general URL syntax a space is %20. The plus-for-space rule comes from the older form-encoding convention; both usually decode to a space server-side, but only %20 is correct in a path or query, and a literal plus must be written %2B so it is not read as a space.

How are accents and emoji encoded?

Percent-encoding works on bytes, so a character is written as its UTF-8 bytes in hex - é becomes %C3%A9 (two escapes) and an emoji becomes several. This is why a single visible character can occupy multiple %XX pairs.

Do I have to encode the ? and & in a URL?

Not the structural ones. A ? starts the query and & separates parameters, so you leave those as-is. But if a ? or & appears inside a single value, that instance must be escaped so the parser does not mistake it for structure.

Does encoding hide data or make it secure?

No. Percent-encoding is reversible formatting, not protection - anything encoded can be decoded instantly. It only makes a value safe to transport in a URL; it is not encryption, hashing or redaction.