URL Encoder — Free Online Tool on Toolpile
Every tool you need, one place
PDF, Image, AI, Dev, and Business tools — free, private, no signup.
Toolpile uses cookies for analytics and ads. The tools themselves keep your files in the browser — that doesn't change. Read the full policy
PDF, Image, AI, Dev, and Business tools — free, private, no signup.
About URL Encoder
URL encoding (also called percent-encoding) is the rule that says any character with special meaning in a URL — and many that don't — gets replaced with `%` followed by its hex byte value. Skip it where it's needed and your URL parses wrong; apply it where it isn't needed and you get `%2520` instead of `%20` (double-encoding). Both bugs are fixable in seconds once you see what the encoder is actually doing.
RFC 3986 (2005) defines a URL as a structured string with reserved characters that have specific meanings: `:` separates the scheme, `/` separates path segments, `?` starts the query string, `&` separates query parameters, `=` joins keys and values, `#` introduces a fragment. If your data contains any of these characters as content (a search term with a slash, a name with an ampersand, a value with an equals sign), they have to be escaped — otherwise the parser interprets them structurally.
The escape format is `%XX` where XX is the hex code of the byte. Space becomes `%20`. `&` becomes `%26`. `=` becomes `%3D`. Non-ASCII characters get encoded as their UTF-8 byte sequences, each byte percent-encoded — `é` (one character, two UTF-8 bytes) becomes `%C3%A9`. Emoji like `🚀` (one character, four UTF-8 bytes) becomes `%F0%9F%9A%80`.
Two reserved-character classes need different encoding behaviour depending on where they appear. In a query string value, `+` is sometimes used as shorthand for space (a leftover from form-encoded bodies, application/x-www-form-urlencoded). In a path component, `+` is a literal plus. JavaScript's `encodeURIComponent` always encodes `+` as `%2B`, which is unambiguous; `encodeURI` doesn't, which is sometimes what you want for full URLs but is a bug for individual components.
JavaScript ships two URL-encoders, and 90% of bugs come from picking the wrong one. **`encodeURI(url)`** assumes its input is a complete URL and only encodes characters illegal in a URL anywhere — it leaves reserved characters like `:`, `/`, `?`, `&`, `=`, `#` alone because they have structural meaning. Use it on a complete URL string when you just need to escape unusual characters in the path or query without breaking the structure: `encodeURI('https://example.com/search?q=hello world')` → `'https://example.com/search?q=hello%20world'` — the `://` and `?` and `=` survive.
**`encodeURIComponent(piece)`** assumes its input is a single component (a path segment, a query value) and encodes every reserved character. Use it on individual pieces before concatenating: `encodeURIComponent('100% off')` → `'100%25%20off'`. Then build: `'/products/' + encodeURIComponent(slug) + '?q=' + encodeURIComponent(query)`.
The bug pattern: passing a full URL to `encodeURIComponent` mangles `://` into `%3A%2F%2F` and breaks every parser downstream. The opposite bug: passing a query value to `encodeURI`, which leaves `&` un-encoded, so a value like `a&b=c` looks like two parameters to the receiver. Always: encodeURIComponent for component-by-component, encodeURI for full URLs you trust to already be structurally correct.
This tool offers both modes — pick "full URL" or "single value" depending on what you're encoding. The default is "single value" because that's the more common need (encoding form input, building URL pieces from user data); switch modes for whole-URL escaping.
**Double encoding**: `%20` becomes `%2520` because someone encoded an already-encoded string. Symptom: spaces showing up as literal `%20` in the rendered page or URL bar, or path segments containing `%25` everywhere. Fix: decode once, then encode once, never both. Frameworks and HTTP clients sometimes encode automatically; doing it manually first is the most common cause.
**`+` vs `%20`** for spaces: `application/x-www-form-urlencoded` (HTML form bodies) uses `+` for spaces. Modern URL components use `%20`. Mixing them up means a search for "hello world" might end up as `hello+world` and the receiver gets confused. JavaScript's `encodeURIComponent` always uses `%20`; if you need form-encoded format, replace `%20` with `+` after.
**Encoding the wrong character set**: encoding `&` inside a value (correct) vs. encoding `&` between key=value pairs (wrong — breaks the URL structure). The receiver sees `?q=hello&filter=red` as two parameters; if you encode the `&` between them to `%26`, you get one parameter `q=hello%26filter=red` which is a single string with an ampersand in it.
**Forgetting to encode `+` in passwords**: passwords with `+` in them, sent in form-encoded bodies, get decoded as spaces by the server. Always `encodeURIComponent` user-supplied values before placing them in a URL or form body.
What's the difference between URL encoding and HTML encoding?
Different escapes for different contexts. URL encoding (`%20`, `%26`) escapes characters with structural meaning in URLs. HTML encoding (`&`, `<`, ` `) escapes characters with meaning in HTML markup. A URL placed inside an HTML attribute may need both — first URL-encode the data, then HTML-encode the result. The two are not interchangeable; using HTML encoding in a URL or vice versa breaks both.
Should I encode the # character in URLs?
If it's part of your data (a username, a hashtag in a search), yes — `%23`. The `#` character introduces a URL fragment; un-encoded `#` in the middle of a query value will be interpreted as the start of a fragment and the rest of the query will be silently dropped by most parsers. The bug is invisible until you test with hashtag data.
Why does my non-Latin URL look like %C3%A9 nonsense?
That IS the URL. RFC 3986 specifies that non-ASCII characters be encoded as their UTF-8 byte sequences, each byte percent-encoded. `é` is `%C3%A9` because its UTF-8 bytes are 0xC3 0xA9. Modern browsers display the decoded version in the address bar (you'll see `é` in Chrome's URL bar) but the actual transmitted URL has the percent-encoded form. Older systems and APIs may need the encoded form explicitly.
What characters never need encoding?
RFC 3986 reserves a set of "unreserved" characters that are always safe: `A-Z`, `a-z`, `0-9`, `-`, `_`, `.`, `~`. Everything else is potentially reserved depending on context. Stick to unreserved characters in IDs, slugs, and any URL component you generate — and percent-encode anything else.
Does this tool support encoding emojis or right-to-left scripts?
Yes. UTF-8 encoding is built into the underlying JavaScript APIs — `encodeURIComponent('🚀 مرحبا')` works correctly, producing the byte-by-byte percent-encoded form. The output looks longer than the input (each non-ASCII codepoint becomes 2-4 bytes, each byte becomes 3 characters in percent-encoding) but decodes losslessly back to the original.