URL Encoder
Encode text for use in URLs (Percent encoding).
About URL Encoder
This page performs component encoding: it escapes everything that is not an unreserved character, including the delimiters that give a URL its structure. That is the right transformation for a single value you are about to drop into a query string, a path segment or a form field — and the wrong one for an entire address, which would come back with its own colons and slashes escaped.
What percent-encoding is for
A URL is a structured string, and a handful of characters carry that structure: a question mark starts the query, an ampersand separates parameters, an equals sign splits a name from its value, a slash divides path segments and a hash begins the fragment. The moment one of those appears inside a value rather than between them, the parser on the other end reads it as punctuation. A search for fish & chips dropped raw into ?q= arrives as a parameter q holding fish plus a second, empty parameter called chips. Percent-encoding removes the ambiguity by replacing each such byte with a percent sign and its two hex digits, so the receiver knows it is data.
Component encoding versus whole-URL encoding
The distinction catches people out constantly, so it is worth being concrete. Encoding the address https://a.com/p q?x=1 as a component produces https%3A%2F%2Fa.com%2Fp%20q%3Fx%3D1 — every structural character escaped, which is exactly what you want when that URL is going to be the value of a redirect_uri or a url parameter. Whole-URL encoding would instead leave the scheme, slashes and query marker intact and escape only the space. Deciding which you need comes down to one question: is this string a URL, or is it a value that happens to look like one?
Non-ASCII text becomes UTF-8 bytes
Anything outside plain ASCII is converted to UTF-8 first and each resulting byte is escaped separately, so a single character can expand to several escapes — two for most accented Latin letters, three for CJK characters, four for an emoji. This is the behaviour every modern server and HTTP client expects, and it is why the output is safe to hand to a backend written in any language. The one input it will refuse is a lone surrogate, the orphaned half of a character pair that turns up when text has been cut at the wrong byte offset; there is no legal encoding for it, so the tool reports a failure instead of guessing.
Two traps: the plus sign and double encoding
A space becomes %20 here, never a plus. The plus convention belongs to HTML form submission, and mixing the two is a classic source of corrupted values — which is also why a literal plus in your input is escaped to %2B, so it cannot be read back as a space. The second trap is running text through an encoder twice: a percent sign is itself escaped, so %20 becomes %2520 and the recipient sees the literal text %20 instead of a space. If a value arrives looking over-escaped, suspect an encode step happening in both your code and your HTTP library.
Scope, and where it runs
Encoding happens in your browser through a built-in function, with no request made and nothing stored, so internal URLs and tokens stay local. Bear in mind what percent-encoding is not: it offers no confidentiality and no integrity, since anyone can decode it in one step. It is also not a security control on its own — escaping a value for a URL does nothing to make it safe inside HTML, SQL or a shell command, each of which needs its own escaping. Note finally that the apostrophe, asterisk, exclamation mark and brackets are deliberately left as-is, which is fine for the web but will break an OAuth 1.0 signature base string unless you escape them yourself.
Escapes Delimiters Too
Ampersands, equals signs, slashes, question marks and hashes are all escaped, not just spaces — so a value containing them cannot be misread as extra parameters by whatever parses the URL at the other end.
UTF-8 Byte Sequences
Accented letters, CJK text and emoji are converted to UTF-8 and escaped byte by byte, producing exactly what a modern server, framework or HTTP client expects to receive and decode.
A Built-In Browser Call
Encoding uses the platform’s own function with no network step at any point, so pasting an internal URL or a token here does not put it on anyone else’s server.
Frequently Asked Questions
Should I paste a whole URL in here?
Usually not. This encodes a component — one value that will sit inside a URL — so it escapes the delimiters too. Paste a full address and the colon and slashes after the scheme come back as %3A and %2F, giving you a string that is no longer a working link. That is correct when the URL is itself a parameter value, as with a redirect_uri or a share link; it is wrong if you were hoping to tidy up an address. For that, only the illegal characters need escaping, and your browser will do it when you paste the URL into the address bar.
Exactly which characters survive untouched?
Letters, digits, and exactly nine punctuation marks: hyphen, underscore, full stop, exclamation mark, tilde, asterisk, apostrophe and the two round brackets. Everything else becomes a percent sign followed by two hex digits: a space is %20, an ampersand %26, an equals sign %3D, a slash %2F, a question mark %3F, a hash %23, a plus %2B and a colon %3A. Note that square brackets are not on the safe list — they become %5B and %5D.
Why is my space %20 and not a plus sign?
Because they belong to different specifications. Percent-encoding, which governs URLs, represents a space as %20. The plus sign comes from HTML form submission, where a browser encodes a space that way when posting application/x-www-form-urlencoded data. Both appear in the wild and the receiving code has to know which it is reading. If your endpoint parses form data and treats a literal plus as a space, encode any real plus in your value as %2B — which this tool does automatically.
What happens to accented characters and emoji?
They are converted to UTF-8 bytes first and each byte is then percent-encoded, which is why one character can produce several escapes. An e-acute becomes %C3%A9, a CJK character becomes three escapes, and an emoji becomes four. This matches what every modern server, language runtime and HTTP client expects, so the output round-trips cleanly.
It said encoding failed. What did I paste?
Almost certainly a lone surrogate — half of a character that is normally stored as a pair, which arrives when text is truncated at the wrong byte or copied out of a mangled log. There is no valid UTF-8 representation for it, so the encoder refuses rather than emitting nonsense. Find the truncation point in your source data and fix it there.
Are the apostrophe and brackets really safe to leave alone?
For ordinary web use, yes — browsers and servers handle them without complaint. There are two places where it matters that this tool leaves them unencoded. OAuth 1.0 signature base strings require the apostrophe, asterisk, exclamation mark and brackets to be escaped, so a signature computed on this output will not match. Some older systems also treat an apostrophe specially. In both cases, escape those characters by hand afterwards.
Is there a length limit?
Nothing is capped here — the box will happily encode many kilobytes. The limit lives downstream. Browsers and servers impose their own caps on how long a URL may be, commonly around 2000 characters for broad compatibility and around 8000 before typical server configurations reject the request outright. If your encoded value is heading past that, send it in a request body instead of a query string.
Is anything I paste transmitted?
No. Encoding is a single built-in browser function call with no network involvement, so the value never leaves this tab. Nothing is stored either. That makes it safe for tokens and internal URLs, subject to the usual caution that the value is visible on your screen and sits in your clipboard afterwards.
How do I reverse it?
Use the URL Decoder, which applies the exact inverse and will return your original text. Note that decoding is not symmetric with form encoding: a plus sign in the input comes back as a plus sign, not as a space, because the decoder follows percent-encoding rules rather than form rules.