URL Encoder
Percent-encode text for safe use in URLs, query strings and form bodies.
URL Encoder tool
Characters that were escaped
| Character | Becomes | Count |
|---|
Reading an encoded URL instead? Use the URL Decoder.
What this tool does
URLs may only contain a restricted set of characters. Everything else has to be written as a
percent sign followed by the two hex digits of each byte — %20 for a space,
%26 for an ampersand. This tool applies that transformation and, just as usefully,
shows you which characters it touched.
The mode matters more than anything else on this page. Encoding a whole URL the way you would
encode a single parameter destroys it: every / and ? becomes an
escape and the address stops pointing anywhere.
Common uses
- Building a search or filter link by hand, where the value contains spaces, ampersands or quotation marks.
-
Putting a redirect target inside a query parameter — the inner URL must be fully escaped or
its own
?and&will be read as part of the outer one. - Escaping a filename or an email address before dropping it into a path segment.
-
Preparing a
curlcommand where the shell and the server would otherwise both try to interpret the same characters. - Writing an
application/x-www-form-urlencodedbody by hand for a test.
A short example
The same string, in two different modes:
Input: https://x.dev/a b?q=1&r=2
Component: https%3A%2F%2Fx.dev%2Fa%20b%3Fq%3D1%26r%3D2
Whole URL: https://x.dev/a%20b?q=1&r=2The first is correct when the URL is a parameter inside another URL. The second is correct when it is the address you want to visit.
Space, plus, and the mode that catches people out
A space has two valid encodings and they are not interchangeable. In a path it must be
%20. In an application/x-www-form-urlencoded body — the format a
plain HTML form posts, and the format many query strings imitate — it may be +.
A literal plus sign in that context has to become %2B, which is why
a+b so often arrives as a b.
Strict mode exists for a narrower reason. encodeURIComponent leaves
!, ', (, ) and * unescaped
even though RFC 3986 lists them as reserved sub-delimiters. Most servers do not care. OAuth 1.0
signatures, S3 request signing and a few strict parsers do.
Worth knowing
Non-ASCII characters are encoded as UTF-8 bytes, so é becomes %C3%A9
— two escapes, not one. If you see %E9 somewhere, that string was produced by
JavaScript's long-deprecated escape() function, which emitted Latin-1 and will not
round-trip through a modern decoder.
Finally, encode once. A value that is already escaped and gets escaped again turns every
% into %25, producing %2520 where you wanted
%20 — the classic double-encoding bug.
Frequently asked questions
Which characters never need encoding at all?
RFC 3986 §2.3 defines a single unreserved set: A–Z, a–z, 0–9 and the four marks - . _ ~. Everything else is either reserved with a structural job or has to be escaped. Escaping an unreserved character anyway is legal but not free: %7E and ~ are equivalent only to code that normalises before comparing, and signature schemes compare byte for byte.
Can I put an encoded slash inside a path segment?
Often not. Apache answers 404 to a path containing %2F unless AllowEncodedSlashes is switched on, Tomcat blocks it by default too, and a proxy that decodes the path before routing splits the segment in two regardless of what the origin allows. When a value may contain a slash — a branch name, a file path — carry it in a query parameter rather than the path.
How do I encode a domain name with non-ASCII characters?
Not with percent-escapes. A host is converted to Punycode instead, so münchen.de resolves as xn--mnchen-3ya.de, and percent-encoding only applies from the path onwards. Browsers perform that conversion quietly, which is why a link can look different in the address bar from the text you pasted, and why domains built out of lookalike letters are a phishing problem.