A query parameter value
Input
search terms & more?Output
search%20terms%20%26%20more%3FThe ampersand and question mark are encoded, so they cannot be mistaken for URL structure.
Further reading
- URL encoding explainedWhat percent-encoding does, which characters need escaping and where, the space and plus-sign problem, and why double-encoding breaks links.
About this tool
URLs may contain only a restricted set of ASCII characters, and several of those carry structural meaning: ? starts a query, & separates parameters, / separates path segments, and # begins a fragment. Percent-encoding replaces anything unsafe with a % followed by its hexadecimal byte value.
The choice that matters is scope. Encoding a value that goes inside a URL is a different operation from encoding a URL as a whole, and using the wrong one is the most common cause of broken links and lost query parameters.
How to use it
- Paste or upload your textDrop a file onto the input pane, use the file picker, or paste the text directly.
- Adjust the options if neededThe defaults suit most input; open Options to change the behaviour.
- EncodePress Encode, or use Ctrl+Enter (Cmd+Enter on macOS).
- Copy or downloadCopy the result, or download it as a .txt file.
Worked examples
Each example below is executed against this tool by the test suite, so what you see is what the tool actually produces.
Non-ASCII characters
Input
caféOutput
caf%C3%A9The é is two UTF-8 bytes, so it produces two percent-escapes.
What to watch for
The details that decide whether a conversion is correct, and where information can be lost without any error being raised.
- Component mode versus full-URL mode
- Component mode (the default) encodes the reserved characters too, which is what you need for a value inside a query string: a search term containing & must become %26 or it will be read as a parameter separator. Full-URL mode leaves the structural characters intact so an entire URL stays functional, encoding only genuinely unsafe characters like spaces.
- What gets encoded, and what does not
- The unreserved characters A–Z, a–z, 0–9, hyphen, underscore, period and tilde are never encoded, per RFC 3986. Everything else becomes percent-escapes in component mode. A space becomes %20, note that the + convention for spaces applies only to HTML form submissions, not to URLs generally.
- Non-ASCII text is encoded as UTF-8 bytes
- Each character is converted to UTF-8 bytes and each byte percent-encoded separately. So é becomes %C3%A9, two escapes for one character, and an emoji becomes four. This is why encoded non-Latin URLs look so long.
- Double-encoding is a real hazard
- Encoding an already-encoded string turns every % into %25, so %20 becomes %2520 and the value arrives with literal escape text in it. If your input already contains percent-escapes, decode it first rather than encoding again.
Limitations
- Component mode intentionally encodes reserved characters, so it must not be applied to a whole URL.
- Cannot detect whether input is already encoded; decode first to avoid double-encoding.
- Processing happens in your browser, so very large inputs are bounded by available memory. Files above roughly 10 MB are handled but will feel slower, and multi-hundred-megabyte files are better suited to a command-line tool.
Questions
- Which mode should I use?
- Component mode for anything going inside a URL, a query value, a path segment, a filename. Full-URL mode only when encoding a complete URL that must remain usable, since it preserves : / ? & and #.
- Should a space become %20 or +?
- %20 is correct in a URL. The + form is specific to application/x-www-form-urlencoded, the format HTML form posts use. Most decoders accept both in a query string, but %20 is always safe.
- Why is my URL broken after encoding?
- You probably encoded the whole URL in component mode, which turns : and / into escapes. Use full-URL mode for a complete URL, or encode only the individual values.