URLs can only contain unreserved characters — letters, numbers, -, ., _, ~ — and the 18 reserved characters (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) plus space and all non-ASCII must be percent-encoded as % followed by two hex digits of the UTF-8 bytes per RFC 3986 §2.1. Encoding "Hello World! & more=100% café" as Hello%20World%21%20%26%20more%3D100%25%20caf%C3%A9 ensures the space, &, =, %, and é are transmitted as data, not misinterpreted as URL delimiters that split the query into wrong keys and values. A URL encoder that implements encodeURIComponent logic per MDN: encodeURIComponent and handles UTF-8 does the conversion without hand-looking up hex codes or double-encoding.
This expanded A-to-Z guide explains how to URL encode text or special characters online — what percent-encoding is per RFC 3986, the unreserved vs reserved vs unsafe vs non-ASCII categories, encodeURI vs encodeURIComponent vs encode +, step-by-step encoding and decoding, common examples (space → %20 vs +, & → %26, é → %C3%A9), when to encode (query values) vs when not to (whole URL), double-encoding pitfalls, and tool comparisons — with references to RFC 3986, WHATWG URL Standard, and MDN.
Hello%20World%21%20%26%20more%3D100%25%20caf%C3%A9) per RFC 3986 — spaces become %20 (or + in application/x-www-form-urlencoded query strings), & → %26, = → %3D, % → %25, and é → %C3%A9 via UTF-8. Use encodeURIComponent logic for query values and decode with the same tool to reverse.
What Is URL Encoding (Percent-Encoding)?
URL encoding (percent-encoding) replaces each unsafe or reserved byte with % followed by two uppercase hex digits representing the byte value per RFC 3986 §2.1. For ASCII, one character is one byte: space (0x20) → %20, ! (0x21) → %21, & (0x26) → %26, = (0x3D) → %3D, % (0x25) → %25. For non-ASCII, the character is first encoded as UTF-8 bytes, then each byte is percent-encoded: "café" → UTF-8 bytes 63 61 66 C3 A9 (é is 2 bytes: C3 A9) → caf%C3%A9. Per WHATWG URL Standard § percent-encode, this is the web's standard and is implemented by encodeURIComponent in browsers.
Character categories per RFC 3986 §2:
| Category | Characters | Encode? | Example |
|---|---|---|---|
| Unreserved | A-Z a-z 0-9 - . _ ~ | Never | abc123-._~ stays |
| Reserved (delimiters) | : / ? # [ ] @ ! $ & ' ( ) * + , ; = | When not as delimiter | & in value → %26 |
| Unsafe / Space | Space, ", <, >, \, ^, `, {, }, | | Always | Space → %20 |
| Non-ASCII | é, 中, 😀 | Always (via UTF-8 bytes) | é → %C3%A9 (2 bytes) |
encodeURI vs encodeURIComponent vs Form + — When to Use Which
| Function | Encodes | Leaves | Use For |
|---|---|---|---|
encodeURI | Space, non-ASCII, unsafe | : / ? # [ ] @ ! $ & ' ( ) * + , ; = (reserved as delimiters) | Whole URL — https://example.com/a & b?x=1&y=2 → keeps : / ? & = |
encodeURIComponent | All reserved + space + non-ASCII | Unreserved only | Query value — a & b → a%20%26%20b for ?q=a%20%26%20b |
Per MDN, use encodeURIComponent for query values and encodeURI for whole URLs. A common bug is encodeURI("https://example.com/?q=a & b") → keeps & and splits the query into q=a and b as a new key. The fix is encodeURIComponent("a & b") for the value: ?q=a%20%26%20b. The online encoder offers both modes and labels them, so the choice is explicit.
+ vs %20 for space: In application/x-www-form-urlencoded query strings (HTML form submit), space is historically + per WHATWG URL Standard; in the path and in RFC 3986, it is %20. The encoder offers both and notes the context; %20 is preferred for URLs, + is accepted for query values and decoded as space by most servers.
How to URL Encode Text Online — 3 Steps
- Paste text: Any text with spaces, symbols, or non-ASCII — e.g., "Hello World! & more=100% café" or a full URL with query. The encoder detects non-ASCII and shows the UTF-8 byte breakdown.
- Choose mode and encode: Select
encodeURIComponent(encode all reserved, for query values — default for text) orencodeURI(leave reserved, for whole URLs). The encoder converts per RFC 3986 — space →%20(or+if form mode),!→%21,&→%26,=→%3D,%→%25, andé→%C3%A9via UTF-8 (2 bytes). Non-ASCII like "café" becomescaf%C3%A9and "中文" becomes 6 bytes of%E4%B8%AD%E6%96%87. - Copy encoded (and decode to verify): The result is ready for query strings, form data, or URL paths. The same tool decodes —
Hello%20World%21→ "Hello World!" — to verify and to debug encoded URLs by making them readable. Copy the decoded to check, then re-encode after editing.
Common Examples — What Becomes What
| Character(s) | Encoded (UTF-8) | When This Matters |
|---|---|---|
| Space | %20 (or + in form query) | Always in query value — ?q=hello world → ?q=hello%20world |
& | %26 | In value, not as & separator — a & b → a%20%26%20b |
= | %3D | In value, not as key=value — a=b in value → a%3Db |
# | %23 | In value, not as fragment — #section in value → %23section |
% | %25 | In value — 100% → 100%25 (percent itself must be encoded) |
| é (U+00E9) | %C3%A9 (2 UTF-8 bytes: C3 A9) | Non-ASCII — "café" → caf%C3%A9 |
| 中文 (U+4E2D U+6587) | %E4%B8%AD%E6%96%87 (3 bytes each) | CJK — 3 bytes per char in UTF-8 |
For "Hello World! & more=100% café": Hello%20World%21%20%26%20more%3D100%25%20caf%C3%A9. In a query string ?q=Hello%20World%21&lang=en, the %20 and %21 are data, while & and = remain delimiters — this is why only the value is encoded, not the whole ?q=...&lang=... with encodeURIComponent on each value separately.
Tips — When to Encode vs Decode and How to Avoid Double-Encoding
- Encode query values, not the whole URL with
encodeURIComponent:encodeURIComponent("https://example.com/a & b")→https%3A%2F%2Fexample.com%2Fa%20%26%20b— the: /are encoded and the URL breaks. UseencodeURI("https://example.com/a & b")for the whole URL (keeps: / ? #) orencodeURIComponentonly on the value:"https://example.com/?q=" + encodeURIComponent("a & b")→https://example.com/?q=a%20%26%20b. - Decode to read, encode to send:
Hello%20World%21→ "Hello World!" via decode to debug; "Hello World!" →Hello%20World%21via encode to send. The same tool does both, so copy encoded, decode to verify readability, then re-encode after editing. - UTF-8 is the web standard: Non-ASCII like "café" and "中文" are first UTF-8 bytes, then each byte is percent-encoded. Per WHATWG URL and RFC 3986, UTF-8 is the encoding for the web — not ISO-8859-1 or Windows-1252. The encoder uses UTF-8 per spec.
- Don't double-encode: Encoding
%20again yields%2520because%→%25—%20becomes%2520, which decodes to%20, not space. If unsure whether a string is already encoded, decode first, then encode once. Double-encoding is the most common bug when a value is encoded in JS and again on the server. - Space:
%20vs+: In the path and in RFC 3986, space is%20; inapplication/x-www-form-urlencodedquery strings (HTML form submit), it is historically+per WHATWG URL Standard § application/x-www-form-urlencoded. Most servers decode both to space, but%20is preferred for URLs and+is accepted for query values. The encoder offers both and labels the context.
FAQs About URL Encoding
How do I URL encode text online?
Paste text into a URL encoder to get percent-encoded ASCII per RFC 3986 — spaces become %20, & → %26, = → %3D, and non-ASCII becomes UTF-8 bytes like %C3%A9 for é — ready for query strings and URLs. No install needed.
What is the difference between encodeURI and encodeURIComponent?
encodeURI leaves reserved characters (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) for whole URLs; encodeURIComponent encodes all reserved for query values. Use the latter for values: ?q=a%20%26%20b for "a & b".
Should I encode spaces as %20 or +?
%20 is standard per RFC 3986 for path and query values; + is legacy for application/x-www-form-urlencoded query strings. Both decode to space on most servers, but %20 is preferred for URLs and + is accepted for form queries.
How do I handle non-ASCII like café or 中文?
They are first UTF-8 bytes, then each byte is percent-encoded: "café" → caf%C3%A9 (é is 2 bytes: C3 A9), "中文" → %E4%B8%AD%E6%96%87 (3 bytes each). The encoder handles UTF-8 per WHATWG URL.
What is double-encoding and how do I avoid it?
Encoding an already-encoded string — e.g., %20 → %2520 because % → %25. It decodes to %20, not space. Avoid by decoding first if unsure, then encoding once.
Do I need to encode the whole URL?
No — encode only the values. Encoding the whole URL with encodeURIComponent would encode : / ? & = and break it. Use encodeURI for the whole URL or encodeURIComponent per value: url + "?q=" + encodeURIComponent(value).
Conclusion
URL encoding is percent-encoding reserved, unsafe, and non-ASCII characters per RFC 3986 — space to %20 (or + in form queries), & to %26, = to %3D, % to %25, and UTF-8 bytes for é and 中文 — so the URL is transmitted without delimiter confusion. Encoding query values with encodeURIComponent (not the whole URL) and decoding to read keeps URLs correct and debuggable, and avoiding double-encoding keeps them from becoming %2520.
Paste the next text — with spaces, symbols, or non-ASCII — to get the encoded and decoded forms ready for the URL, query, or form, with UTF-8 handling per the web standard.
