Paste text or a link and see it become percent-encoded as you type — pick component, URI, or form encoding depending on where it's going.
Files never leave your device
Component escapes the most characters, for a single value. Full URI leaves URL punctuation like / and ? alone. Form also turns spaces into +.
A URL can only contain a limited alphabet safely. Anything else — a space, an ampersand that isn't
a separator, an accented letter — has to be rewritten as a percent sign followed by two hex digits,
one triplet per byte. This page does that rewriting for you, in your browser, in whichever of the
three encodings actually matches where the text is going.
The unreserved set, and everything outside it
Every URL parser agrees on one thing without exception: letters, digits, and the four punctuation
marks - . _ ~ never need escaping and never mean anything special. That's the unreserved set.
JavaScript's own encoder — what runs behind this page — also leaves five more marks alone, ! * ' ( ), a holdover from an older spec that most tools still honor today. Outside that combined set,
two more groups exist — characters URL syntax already uses as delimiters (/ ? # : @ & = and
others), and everything else, from a plain space to a full sentence in Vietnamese. Encoding's job is
deciding which of those remaining groups to touch.
Example 1: a space, three ways
hello world encodes to hello%20world in both component and full URI mode — a space is not part
of the unreserved set, so both escape it the same way. Form mode instead produces hello+world,
because a submitted HTML form has always used + for a space rather than %20.
Example 2: a literal plus stays a plus
Encode a+b and every mode returns a%2Bb — except full URI mode, which returns a+b unchanged,
since + is not one of the characters it protects. That asymmetry matters: in component and form
mode, + in your input is escaped so it can never later be misread as a stand-in for a space, while
full URI mode assumes you already know what a + in your address means and leaves it alone.
Tip:Building a query string field by field? Encode each value with component or form mode on its own, never with full URI mode on a single value — full URI mode won't escape & or =, so a value containing one will be misread as an extra parameter once it lands in the query string.
Example 3: non-ASCII text, byte by byte
Tiếng Việt becomes Ti%E1%BA%BFng%20Vi%E1%BB%87t in component mode — each accented letter is
first turned into its UTF-8 bytes, then every byte becomes its own %XX triplet. ế alone takes
three bytes and three triplets, %E1%BA%BF; a plain ASCII letter like T needs none. Form mode
gives the same result with the one space rewritten as +: Ti%E1%BA%BFng+Vi%E1%BB%87t.
Component, full URI, or form
Mode
Escapes / ? # & =
Escapes space as
Typical use
Component
yes
%20
One value — a search term, a path segment, a redirect target
Full URI
no
%20
An entire address you're normalising, not building
Form
yes
+
A value going into an HTML form submission or its query string
Tip:Not sure which to pick? Component is the safe default for anything smaller than a whole URL — reach for full URI only when you're encoding an address you intend to keep navigable, and for form only when the destination is literally a form submission or reads query strings the way one does.
Why full URI mode exists at all
If component mode is always safe for a fragment, it would seem like the obvious default everywhere.
But run a complete address through it and every / and ? gets escaped along with the spaces,
turning https://example.com/a b into an unnavigable string of percent signs instead of a working
link with one escaped space. Full URI mode exists precisely for that case — normalising an address
a person typed by hand without destroying the structure that makes it an address.
Frequently asked questions
What's the difference between component, full URI and form encoding?
Component encoding escapes everything a URL treats as punctuation, so it is safe for one value that is going to sit inside a larger URL — a search term, a redirect target, a single query value. Full URI encoding is gentler: it leaves the characters that give a URL its structure — / ? # : @ & = — alone, because it assumes you are encoding a whole address, not a fragment of one. Form encoding is component encoding with one change, spaces become + instead of %20, matching how a browser submits an HTML form.
Why does form mode turn a space into a plus sign instead of %20?
Because that is the actual wire format for application/x-www-form-urlencoded, the encoding an HTML form uses when it submits with method="get" or a plain POST body. It predates percent-encoding spaces and every server-side framework still expects + for a space in that context. %20 is also technically valid there, but + is what a browser sends, so matching it avoids a mismatch with server code that only checks for +.
Why does encoding "a+b" produce "a%2Bb" instead of leaving the plus alone?
A literal plus in your input is data, not a stand-in for a space — you typed it because you meant the character +. Encoding always escapes it to %2B so a decoder reading it back gets a plus, not a space. The reverse mapping — space becomes + on encode, but only in form mode — only runs in one direction, so a real plus is never mistaken for an encoded space.
Which characters does this leave alone?
The unreserved set: uppercase and lowercase letters, the digits 0 to 9, and four punctuation marks — hyphen, period, underscore and tilde. Those are guaranteed to mean the same thing in every URL parser and never need escaping. The JavaScript encoder behind this page also leaves five more marks untouched — ! * ' ( ) — a carryover from an older spec. Everything else — other punctuation, and any character outside ASCII — becomes a percent-encoded triplet in both component and form mode; a space is the one exception, becoming %20 in component mode but + in form mode. Full URI mode also leaves the URL's own structural characters alone.
Can encoding ever fail?
Not in a way this page reports as an error. The one edge case is a lone UTF-16 surrogate — half of a pair with no partner, which normally cannot happen from typing but can arrive from a corrupted copy-paste. Since that half-character has no valid encoding, it is replaced with the standard Unicode replacement character before encoding runs, rather than throwing partway through your text.
Is the text I type here uploaded anywhere?
No. Encoding runs in JavaScript inside your browser tab the moment you type, and no request carries your input off the device. Open your browser's network panel while using this page and you will see nothing related to the text itself — useful when what you are encoding is a token, an internal URL, or anything else you would rather not send to a server just to convert it.
When should I pick full URI mode instead of component mode?
When you already have a complete address and only want to escape the parts that are unsafe to leave as-is — spaces in a path, or non-ASCII characters in a domain or path segment — while keeping the / ? # and = that give the address its shape. Run a single query value through full URI mode instead and its own & or = characters won't be escaped, so they can be read as extra delimiters and corrupt the query you're building.