URL Encoder / Decoder
Percent-encode text for URLs and query strings, or decode an already encoded URL. Switch between encodeURIComponent for single values and encodeURI for
Percent-encode text so it can travel safely inside a URL, or decode a link you copied from a log or an email. Values such as spaces, ampersands, question marks and non-Latin characters must be escaped before they go into a query string, and this tool shows exactly what the encoded form looks like.
Two modes matter: encoding a single value (a search term, an email address, a token) escapes every reserved character, while encoding a complete link leaves the structural characters - the slashes, the question mark, the ampersand - intact. Picking the wrong one is the classic cause of a broken redirect, so the mode is selectable.
How to encode and decode a URL
Paste text or a URL
Choose value mode or full-link mode
Copy the encoded or decoded result
FAQ
What is the difference between the two modes?
Value mode escapes reserved characters such as & = ? / #, which is what you need inside a query parameter. Full-link mode keeps those characters so a complete URL stays usable.
Why does a space become %20 or +?
%20 is the standard percent encoding. The plus sign is a legacy convention from HTML form submissions and is only equivalent inside a query string, not in a path.
Can it decode as well as encode?
Yes, decoding works in both directions and shows the original characters, including accented and CJK text.
Why does decoding fail on my string?
A stray % that is not followed by two hexadecimal digits is invalid and cannot be decoded. Check for a truncated value or a percent sign that was meant literally.
Does it handle non-Latin characters?
Yes, text is encoded as UTF-8 first and then percent-encoded, which is the form browsers and servers expect.
Is my input uploaded?
No, encoding and decoding are pure text operations in your browser.
At a glance
| Input | text |
|---|---|
| Multiple files | No |
| Where it runs | In your browser - files are never uploaded |
| Works offline | Yes — once the page has loaded |
| Price | Free, no sign-up, no watermark |
Choosing a data format
JSON is the default for anything an API returns or a program reads: it handles nested structures, numbers, booleans and null naturally, and every language parses it. CSV is smaller and opens straight into a spreadsheet, but it has no way to express nesting and no shared standard for the delimiter, quoting or character set - which is exactly where conversions go wrong. XML is verbose but carries attributes, mixed content and schemas, so it still dominates document formats and legacy integrations. YAML is the most readable for configuration but is whitespace-sensitive and has surprising type coercion ("no" becoming false, a version like 1.10 becoming 1.1). Pick the format the consuming tool prefers rather than the one that looks nicest.
Where conversions quietly break
Most conversion bugs are not about syntax, they are about meaning. A CSV column of postcodes loses its leading zeros the moment a spreadsheet guesses it is a number; a long ID exceeds floating-point precision; dates change meaning depending on whether they are day-first or month-first. JSON keys are unordered but arrays are not, and a tool that sorts keys changes nothing while one that sorts arrays changes the data. Unicode is another trap: text can arrive as UTF-8, UTF-16 or with a byte-order mark, and a decoder that guesses wrong turns accented characters into mojibake. Before trusting any conversion, spot-check the first and last row, any field with leading zeros, and any field containing quotes, commas or newlines.