URL Encoder and Decoder
Percent-encode a URL or decode it back so it works correctly in query strings and forms — instantly.
Your text stays on your device
Nothing to delete afterwards
Safe for URLs with tokens
Works in every modern browser
How it works
- 1
Paste your text or URL
A parameter value to encode, or a percent-encoded string to read back.
- 2
Choose where it is going
A whole URL, or a single component that sits inside one — the rules differ.
- 3
Copy the result
Take it into a link, a request, a redirect target, or a config value.
Why use this tool
Component and full-URL modes
Encode a single parameter value or a whole address — they need different rules, and mixing them is the usual bug.
Space handled explicitly
Choose `%20` or `+`, because a query string and a path segment disagree about which one means a space.
Double encoding avoided
Already-encoded input is recognised, so `%20` does not quietly become `%2520`.
UTF-8 done properly
Arabic, Turkish, and accented characters become the correct byte sequences rather than mangled output.
Nothing is uploaded
The conversion happens in your browser — a URL carrying a session token never reaches a server.
Free, no account
No signup, no watermark, no cap on how much you convert.
There is no single "URL encoding" — there are two, and they disagree
This is the fact that resolves most of the confusion around this task. Encoding a whole URL and encoding one piece that goes inside a URL are different operations with different rules, and using the wrong one is the most common way a link breaks. A full address needs its `/`, `?`, `&`, `#`, and `:` left alone, because those are the punctuation that gives the address its shape. A single value — a search term, a redirect target, a filename in a parameter — needs exactly those characters escaped, because inside a value they are data rather than structure. Encode a whole URL with component rules and you get an unusable string of `%2F` and `%3A`. Encode a component with full-URL rules and a slash in your value silently becomes a path separator. Decide which one you are doing before you start.
Where in the address you are decides what needs escaping
It follows from the above, and it is worth stating directly because it explains the cases that seem inconsistent. A slash inside a path is a separator and must stay a slash; a slash inside a query parameter value is just a character and can stay too, though escaping it is safer. A question mark in the path begins the query string; the same character inside a parameter value must be `%3F` or everything after it is read as more parameters. An ampersand inside a value is the sharpest case: leave it raw and the value is split in two, so a search for "R&D" arrives as a parameter called `D`. The rule to carry is that reserved characters are only reserved where they can do their job, and inside a value they cannot, which is exactly why they must be escaped there.
The plus sign means two different things, and both are correct
Space is the character everyone meets first and the one with the messiest history. Percent-encoding says a space is `%20`, and in a path segment that is the only correct answer — a literal `+` in a path is a plus sign and nothing more. But HTML form submission defined its own encoding for query strings, in which a space is `+` and a literal plus must be written `%2B`. Both conventions are alive, both are correct in their own context, and decoders treat them differently: a decoder in query-string mode turns `+` into a space, one in path mode leaves it alone. That is why a value containing a plus — a phone number in international format, a tagged email address like `name+work@example.com` — arrives with the plus replaced by a space so often. If your value can contain a literal plus, escape it as `%2B` and stop depending on which convention the receiver picked.
Double encoding is the bug you will actually hit
Because `%` introduces an escape sequence, the percent sign itself has to be encoded, as `%25`. That single rule creates the most common failure in this whole area. Encode a string twice and `%20` becomes `%2520`, because the `%` in the first result is escaped by the second pass. The result decodes once into `%20` — visible, literal, in the middle of your value — instead of a space. This happens constantly in practice: a URL is encoded by an application, then encoded again by a framework, a redirect handler, or a link tracker that assumes it received raw text. The symptom is a link that works in one place and shows `%2520` or `%253A` somewhere else. When you see a `25` sitting in front of another escape sequence, you are looking at a double encode, and the fix is to remove a step rather than decode twice.
Non-ASCII characters are encoded as bytes, not as characters
Percent-encoding has no concept of letters. It escapes bytes, which means any character outside ASCII has to be turned into bytes first, and the standard for that is UTF-8. This is why one Arabic letter becomes three escape sequences and an emoji becomes four — you are seeing its UTF-8 bytes written out one at a time. The consequence worth knowing is that an encoder using a different character set produces different output for the same input, which is how a URL with a name in it works on one system and returns a 404 on another. There is also a second mechanism people confuse with this: a non-ASCII domain name is not percent-encoded at all but converted to Punycode, an entirely separate scheme that produces the `xn--` prefixes you sometimes see. Path and query use percent-encoding; the host does not.
Why encoding locally matters for this kind of text
Think about the URLs people paste into an encoder. It is a callback address with a session token in the query string. It is a signed link with an expiring signature parameter. It is a password reset URL someone is debugging, a webhook endpoint with a shared secret, an internal admin address that reveals a hostname. URLs carry credentials in their query strings far more often than people notice, precisely because a query string looks like configuration rather than a secret. Pasting one into a hosted encoder sends the whole thing to a third party, and if that URL contains a working token, you have just shared a live credential. This tool converts inside the page and transmits nothing, which you can confirm in the Network tab of your developer tools.
Common mistakes to avoid
- Encoding a whole URL with component rules. The `/` and `:` become `%2F` and `%3A` and the address stops being an address — full URLs and values inside them need different rules.
- Leaving an ampersand raw inside a parameter value. It splits the value in two, so a search for "R&D" arrives as an extra parameter called `D`; escape it as `%26`.
- Assuming `+` always means a space. It does in a query string and does not in a path, so a literal plus in a phone number or a tagged email address should be written `%2B` regardless of context.
- Encoding something that was already encoded. The `%` gets escaped as `%25`, so `%20` becomes `%2520` and decodes into visible text instead of a space — remove a step rather than decoding twice.
- Pasting a callback or reset URL into a hosted encoder. Query strings carry session tokens and signatures far more often than people notice; encode locally.
How it compares
| Aspect | This tool | Online encoders | A browser console |
|---|---|---|---|
| Content sent to a server | Never | Usually yes | No |
| Component vs full-URL modes | Both, explicit | Often only one | Two separate functions |
| Space convention selectable | Yes | Rarely | No |
| Double encoding detected | Yes | Rarely | No |
| Account or signup | Not needed | Often required | Not needed |
| Price | Free | Free / paid tiers | Free |
Features
Encode and decode
Both directions in one place, with input and output side by side.
Full URL vs component
The first preserves `/`, `?`, and `&`; the second escapes them, because inside a value they are data.
Space as `%20` or `+`
Match the convention of the context the value is travelling through.
Correct UTF-8 byte sequences
Non-ASCII characters are encoded byte by byte, as the standard requires.
Handles long input
Whole query strings and long redirect chains convert without a size cap.
Malformed input flagged
A stray `%` or an incomplete escape sequence is reported instead of silently dropped.
Nothing to install
No console, no runtime, no dependencies — it runs on the web page.
Arabic and RTL ready
Full interface in eight languages, including right-to-left Arabic.
Secure by default
Served over HTTPS, with no content tracking and no third-party upload.
Who uses it
Developers
Building a query parameter that survives whatever the receiving system does to it.
API integrators
Encoding a redirect target or callback address without breaking the URL that contains it.
Marketers
Making campaign parameters safe when the value contains spaces, ampersands, or non-Latin text.
Support engineers
Reading back a customer-supplied link to see what the parameters actually say.
Frequently Asked Questions
No. Everything runs locally in your browser — your text is never uploaded, stored, or shared.
Yes — completely free, with no account and no limits.