URLs can only safely contain a limited set of characters — spaces, ampersands and accented letters all cause problems if left as-is. This tool percent-encodes your text so it can travel safely inside a URL.
A restriction baked into the earliest web standards
The original URL specification, formalized in RFC 1738 in 1994 and refined through later standards, deliberately reserved certain characters (like &, ?, # and /) for structural purposes within a URL's syntax — separating query parameters, marking fragment identifiers, and delimiting the path. Because of this, any of those reserved characters (or non-ASCII characters like accented letters or non-Latin scripts) appearing as actual data within a URL, rather than as structural punctuation, has to be "escaped" using percent-encoding so a browser or server can correctly distinguish structural syntax from literal content.
How percent-encoding works
Each character that isn't in the URL-safe set gets replaced with a percent sign followed by its two-digit hexadecimal byte value — a space becomes %20 (or, in one common alternate convention for query strings, a + sign), an ampersand becomes %26, and non-ASCII characters are first converted to their UTF-8 byte representation, then each of those bytes is percent-encoded individually.
Where URL encoding is genuinely necessary
- Passing user-generated text as a query parameter — search terms, form input or any dynamic text included in a URL's query string needs encoding to safely handle spaces, special characters and non-Latin scripts.
- Constructing API request URLs — building requests programmatically where parameter values might contain reserved characters requires encoding to ensure the server correctly parses the intended structure.
- Sharing links with special characters — a URL pointing to a file or resource with spaces, accented characters, or symbols in its name needs encoding to function reliably across different browsers and systems.
- Embedding a full URL as a parameter within another URL — redirect URLs, callback URLs and similar "URL within a URL" patterns require careful encoding to avoid the outer URL misinterpreting the inner one's structural characters.
Frequently asked questions
Why do I sometimes see + instead of %20 for spaces? Both are valid depending on context — %20 is the strictly correct percent-encoding for a space anywhere in a URL, while + is a legacy convention specifically for encoding spaces within a URL's query string, originating from HTML form submission standards, and the two aren't universally interchangeable outside that specific context.
What's the difference between encodeURIComponent and encodeURI in JavaScript? encodeURIComponent encodes a wider set of characters (including reserved ones like & and ?), making it the right choice for encoding an individual parameter value, while encodeURI leaves structural URL characters untouched, making it appropriate for encoding an entire URL that should retain its existing structure.
Do I need to encode every character in a URL? No — only characters outside the URL-safe set (letters, digits, and a small set of punctuation like -, _, . and ~) need encoding; over-encoding already-safe characters is unnecessary though generally harmless.
Further reading
RFC 3986 — Uniform Resource Identifier (URI): Generic Syntax — The current standard defining reserved characters and percent-encoding rules.
MDN — Percent-encoding — Practical guide to when and how to apply URL encoding in web development.