How to decode a URL
- Paste the encoded URL or query string into the left URL-encoded text box, the readable version appears live on the right.
- Spot
%25in the output? That's an escaped percent sign, meaning the string was encoded twice, copy the output back into the input and decode again to peel off the extra layer. - Press Copy output to take the decoded text, or load Sample to see a fully-escaped URL turn back into a legible address.
- Use ⇄ Swap to re-encode the result and check the round-trip.
Reading percent-encoding at a glance
Decoding reverses percent-encoding: every %XX sequence is read as a hexadecimal byte and turned back into the character it represents. %20 becomes a space, %3D becomes =, %26 becomes &, and %2F becomes /. Multi-byte UTF-8 sequences reassemble too, so caf%C3%A9 reads back as café and %F0%9F%91%8B comes out as a waving-hand emoji. That's the whole point of this tool: encoded URLs are perfect for machines and painful for people, so paste the wall of percent signs from a server log, a redirect chain, or an analytics utm_* parameter and read it like a sentence.
The double-encoding trap
The most confusing thing you'll hit when decoding is a URL that was encoded more than once, and the tell-tale sign is %25 everywhere. Because % itself is byte 0x25, encoding an already-encoded string escapes each existing % into %25, so a real space that was once %20 becomes %2520. This usually happens when a value passes through two systems that each encode it, or a developer calls an encode function twice. The fix is simple: decode once, and if the result still contains %XX sequences, decode again. Each pass removes exactly one layer, so keep going until the text stops changing.
Where you'll actually reach for this
Decoding earns its keep in the moments when a URL stops being clickable and starts being evidence. You'll paste a redirect_uri or state value from an OAuth flow to check the callback really points where you expect. You'll unpick a marketing link stuffed with utm_source, utm_campaign and a doubly-encoded destination to see where a click ultimately lands. You'll read server-log entries where every query parameter arrived pre-encoded, or inspect an API request that a client library escaped before sending. In each case the encoded form is what the machine stored, and the decoded form is what you need to reason about, so decoding is the first step in almost any URL debugging session.
Frequently asked questions
How do I decode a URL-encoded string?
Paste it into the input box and every %XX sequence and + sign is converted back to its original character instantly, including multi-byte UTF-8 sequences like %C3%A9, which reads back as é.
Why is my URL full of %25 sequences?
%25 is an escaped percent sign, which means the string was encoded twice. Decode once and you'll see ordinary %20-style sequences; decode that result again to reach the original text.
Does + mean a space in URLs?
In query strings submitted by HTML forms, yes, + stands for a space. This decoder converts + to a space automatically, matching how web servers interpret application/x-www-form-urlencoded data.
Why did some characters not change?
Unreserved characters, letters, digits, and - _ . ~, were never escaped in the first place, so there's nothing to decode. Only the %XX sequences and + signs are transformed; everything else passes through as-is.
How do I encode text back into a URL?
Use the URL Encode tool, where you can pick component or full-URI encoding, or simply press ⇄ Swap here to re-encode the decoded text.
Is it safe to paste URLs containing tokens?
Yes. Decoding runs entirely in your browser, URLs with session tokens, API keys, or personal data are never uploaded or logged and never leave your machine.