URL encode
Percent-encode text so it survives a URL. Three different encodings exist for three different jobs, and picking the wrong one is how values silently break — so the page tells you which you want.
- Never stored
- No queue, no waiting
- No signup, no watermark
Encoded appears here.
How it works
Paste your text
Any text, in any language. It is encoded as UTF-8, which is what every modern server expects.
Pick the job
One value going into a query string, a whole assembled URL, or a form submission. The difference matters and each is explained.
Copy the result
Encode line by line if you have a list to do at once.
Three correct answers, and why one button is wrong
Percent-encoding replaces a character with a % and its byte value in hex. The specification divides characters into three groups, and everything confusing about this follows from that. Unreserved characters — letters, digits, hyphen, full stop, underscore and tilde — never need encoding. Reserved characters — the slashes, question marks, ampersands, equals signs and colons that give a URL its structure — must be encoded *when they are data* and must not be *when they are structure*. Everything else is always encoded.
That is why there is no single right answer. Encoding a whole URL has to leave the slashes and the question mark alone, or the address stops being an address. Encoding a value to put in a query parameter must escape ampersands and equals signs, or a value containing one splits into two parameters. Encoding a path segment must escape slashes, or a filename with a slash in it becomes two directories. A single Encode button picks one of these and is wrong the other two thirds of the time — usually silently, and usually in a way that only shows up with unusual input.
Space is the character with the most history attached. In a URL it is %20. In a submitted HTML form it is a +, which is a separate, older encoding that survives because forms have worked that way since 1994. Both are correct in their own context and neither is correct in the other, which is why a plus sign in a query string is ambiguous in a way no amount of care at the encoding end can fix.
Non-ASCII text is encoded as UTF-8 first and then byte by byte, so a single accented letter becomes two percent sequences and an emoji becomes four. Double encoding is the classic bug: encoding something already encoded turns every % into %25, so %20 becomes %2520 and the other end receives a literal percent sign. If a URL is full of %25, it has been through one encoder too many.
When you want something else
In code, use the language's own function and choose it as deliberately as this page makes you. JavaScript has encodeURI for whole addresses and encodeURIComponent for values; Python has urllib.parse.quote with a safe argument that defaults to leaving slashes alone; PHP distinguishes rawurlencode from urlencode, which differ on exactly the space-versus-plus question above. Better still, build URLs with a URL type rather than by joining strings, and the question disappears.
At the command line, jq -rR @uri encodes safely and handles a list, and curl --data-urlencode builds a correctly encoded parameter without you having to think about which of the three cases you are in — which is the one place this is genuinely easy.
Frequently asked questions
Which of the three should I use?
Component, almost always. Use it when you are encoding ONE value that is about to go into a query string or a path segment — a search term, an email address, a redirect target. It is the only one of the three that escapes &, =, ? and /, which is exactly what stops your value breaking out of its parameter and becoming two parameters. Use full-URI only when you already have a complete URL and just want its unsafe characters cleaned up; it deliberately leaves the structural characters alone so the URL stays a URL. Use form when you are building an application/x-www-form-urlencoded body, where a space is + rather than %20.
Why did my "&" break the URL?
Because it was not encoded, and & is how a query string separates one parameter from the next. A value of "Smith & Sons" appended raw to ?company= arrives at the server as company=Smith and a second, empty parameter called "Sons". It is the single most common URL bug, and component encoding is the fix — it turns & into %26 so the value stays one value.
Why did my "+" become a space?
Because in a query string, + means space — a rule inherited from HTML forms that nothing has ever been able to remove. So a literal plus in your data, in a phone number or a Base64 string, is read as a space by the receiving server. Component encoding escapes it to %2B, which arrives intact.
Does it handle other languages and emoji?
Yes. Text is converted to UTF-8 first and then percent-encoded byte by byte, which is what RFC 3986 requires and what every modern server expects. Japanese, Arabic, accented Latin and emoji all round-trip exactly.
Why are ! ' ( ) * encoded here when other tools leave them?
Because the browser's built-in encodeURIComponent leaves those five alone, and RFC 3986 lists them as reserved. Some servers and frameworks treat them structurally, so a value containing them can be misread. Encoding them is harmless — they decode back identically everywhere — and it removes a class of rare, hard-to-diagnose bug. This is what careful implementations do.
Is my text stored anywhere?
No. Nothing is stored and no request is made. You can disconnect from the internet after the page loads and it keeps working.
Good to know: There are three different correct answers and the page makes you pick, because the usual single Encode button is wrong two-thirds of the time. Encoding a whole URL, a query parameter and a path segment escape different characters; using the wrong one silently breaks slashes, plus signs or ampersands.
Put this tool on your website
Free for any blog, class page or help article. Paste one snippet and your visitors can use it right on your page.