URL encoder & decoder
What the URL encoder and decoder does
This app uses one box rather than separate encode and decode fields. Paste plain text and it encodes it, converting spaces, ampersands, question marks and other characters unsafe in a URL into percent-encoded bytes. Paste something that already looks percent-encoded, containing a sequence like %20, and it decodes it back into readable text instead.
It runs on your device. Paste, convert, copy. Nothing you paste is uploaded.
The problem
Why some characters can't go straight into a URL
A URL has a small safe alphabet: letters, digits, and a handful of punctuation marks. Everything else, a space, an ampersand, a question mark inside a value, any non-ASCII character, has to be represented as a percent sign followed by two hex digits, or it risks being misread as part of the URL's own structure.
This matters most in a query parameter: a search term with a space, an email address used as a value, a title with an ampersand, all need encoding before riding safely inside a link.
Workflow
How to encode or decode a URL in three steps
There's only one box, and the app decides the direction automatically.
- Step 1
- Paste the text or URL you want to convert.
- Step 2
- Press Convert. Already percent-encoded input gets decoded; anything else gets encoded.
- Step 3
- Copy the result.
What changes
What actually gets encoded, and what doesn't
Letters, digits and a small set of safe characters are left exactly as they are. Everything else, spaces, ampersands, question marks, colons, slashes and accented or non-Latin characters, is converted to one or more percent-encoded bytes.
A space becomes %20. An ampersand becomes %26. An accented letter or non-Latin character becomes several percent-encoded bytes.
Why it matters
What an unencoded value actually breaks
An unencoded ampersand inside a query value gets read as the start of the next parameter, silently corrupting the data. A literal space can break a URL entirely, since URLs aren't supposed to contain raw spaces.
Decoding has its own failure mode: a stray percent sign not followed by two hex digits produces an error rather than a guess.
Straight answer
How does it know whether to encode or decode?
It looks for a percent sign followed by two hex digits, a pattern unique to already-encoded text. If it finds one, it decodes; otherwise it assumes plain text and encodes.
A coincidental percent-and-two-characters sequence in plain text could be misread, so check the result if it looks wrong. This comes up more than it sounds: a discount code written as '50%OF' followed by a digit, or a percentage figure sitting right next to two hex-looking characters, is enough to trigger the decode path by accident on text that was never encoded in the first place.
Who it's for
Who uses the URL encoder and decoder, and when
Developers use it to build a query string, encoding a search term or redirect URL before dropping it into a link, and to decode a URL pulled from server logs back into something readable.
Anyone debugging a broken link uses it to see exactly what a percent-encoded sequence represents.
The exceptions
Five characters that stay unescaped, and why that can matter
Encoding here follows the same rule as encodeURIComponent everywhere else: letters, digits, and a short list of punctuation, hyphen, underscore, period and tilde, pass straight through. Five more characters also survive unescaped for historical reasons built into that standard: !, *, ', ( and ).
Most of the time that's harmless, since those five are legal inside a URL component anyway. It matters on a system expecting strict RFC 3986 encoding, where those particular characters are supposed to be escaped in certain contexts, an AWS request signature is the most common place this actually bites. If a signature or a strict validator rejects an otherwise-correct encoded value, this is the first thing worth checking.