🔗 URL Encoder / Decoder
Encode or decode URLs and query strings instantly
✓ Free Forever · ✓ No Signup · ✓ No Upload · ✓ Works Offline
🔒 Your data never leaves your device. All processing happens locally in your browser using encodeURIComponent / decodeURIComponent (one value, RFC 3986), whole-URL mode that keeps the URL's structure, + as space (application/x-www-form-urlencoded). No upload, no server, no tracking.
Features
- Encode URLs — Percent-encode special characters for safe use in URLs and query strings.
- Decode URLs — Convert percent-encoded strings back to readable text.
- Unicode Support — Handles all Unicode characters including emoji, CJK, and special symbols.
How It Works
- Enter text — Type or paste the text you want to encode or decode.
- Click Encode or Decode — The tool converts your input instantly.
- Copy the result — Copy the encoded or decoded output to your clipboard.
Use Cases
- Encode query parameters for API URLs
- Decode URLs copied from browser address bars
- Prepare strings for use in HTTP requests
Frequently Asked Questions
What characters are encoded?
All characters except A-Z, a-z, 0-9, and - _ . ~ are percent-encoded. This follows the RFC 3986 standard.
Does it handle full URLs?
Yes. Tick "Whole URL": encoding then leaves : / ? # & = and any %XX already in the address alone (no %2520 double-encoding) and only escapes spaces, accents, emoji and the like; decoding keeps escaped & = ? # / escaped, so the address still means the same thing. Leave it off to encode a single value, for example a URL you are putting inside another URL's redirect= parameter.
Why do I see + instead of spaces?
Query strings and HTML forms (application/x-www-form-urlencoded) write a space as +. Google search URLs do this, for example. Tick "+ means space" and a + is read as a space when decoding, and a space is written as + when encoding; a real plus is always %2B. In a whole URL only the part after ? is treated that way, because in a path a + is just a plus.
Notes from Milo 🐨
I decoded a Google search link here and got "café+crème" — the + is how search boxes and web forms write a space, and the decoder kept it as a plus with no way to say otherwise. Worse, decoding a whole link turned an escaped & inside a value into a real one, so the address quietly meant something else, and encoding a whole link escaped its : and / so it stopped being a link at all. There are two ticks now: "Whole URL" keeps the address's structure (and never double-encodes a %20 that's already there), and "+ means space" reads and writes form-style spaces. If the page sees a + or a whole link and you haven't ticked the matching box, it says so and fixes it in one click.
I pasted a link with a stray "%" into the decoder and all it said was "URI malformed" — the browser's own words, in English, whatever language you read this page in, and no hint where the problem was. It now tells you which bit is broken and where ("%2G at character 7 isn't a valid escape"), in your language, with the browser's message kept underneath in small print for anyone who wants it. While I was in there: Base64 decoding now takes the URL-safe kind with - and _ and missing = padding (so a JWT segment just works), and says plainly when the Base64 is an image or file rather than text; HTML decoding knows every named entity ( , ©, é) and emoji like 😀 instead of turning them into the wrong character; and URL encoding now also escapes ! ' ( ) *, which the FAQ always said it did.
Related Tools
- Image to Base64 — Turn an image into a Base64 data URI, or encode and decode Base64 text — and turn Base64 back into a file
- #️⃣ Hash Generator — Generate cryptographic hashes from text or files
- { } JSON Formatter & Beautifier — JSON pretty-print, beautifier, minifier, and validator — all in your browser
💬 Bug, idea, or just to say hi? Tell Milo 🐨 · [email protected]