URL Encoder Decoder Guide
URL Encoder Decoder handles a small but constant source of bugs in web development: URLs can only safely contain a limited set of characters, and anything outside that set — spaces, ampersands, slashes inside a parameter value, non-English characters, emoji — needs to be percent-encoded into a URL-safe representation before it's placed into a URL, or it risks being misinterpreted, truncated, or rejected outright by whatever is parsing it. A space in a URL becomes %20, an ampersand inside a value that isn't meant to separate parameters becomes %26, and so on, following a standardized encoding scheme that every browser and server understands consistently.
This tool encodes plain text into its URL-safe percent-encoded form, and decodes percent-encoded text back into its original readable form, directly in your browser. It typically supports both the general percent-encoding used in URL paths and the slightly different encoding conventions used specifically within query parameters, since JavaScript's encodeURIComponent and encodeURI functions handle a few characters differently depending on which part of a URL they're meant to appear in.
Getting encoding wrong is a common, frustrating source of bugs precisely because it often appears to work for the common case — a URL with simple ASCII text and no special characters needs no encoding at all — and only breaks once a user enters something with a space, an ampersand, or a non-Latin character, by which point the bug report comes from production rather than from testing with an obviously tricky input.
Because encoding and decoding are exact, reversible, well-defined transformations rather than anything requiring judgment, this tool is most useful as a quick verification step: confirming exactly what a given encoded string actually decodes to, or confirming that a value you're about to place into a URL is properly encoded before it causes a parsing problem somewhere downstream.
How to encode or decode a URL
- Choose encode or decode. Select whether you have plain text that needs to become URL-safe, or an already-encoded string (full of percent signs and hex codes) that you want to turn back into readable text. The tool's behavior switches entirely based on this choice, since the two operations are exact inverses of one another. There's no harm in selecting the wrong direction by mistake, since the tool simply produces an unexpected result rather than corrupting anything, and switching back to try the other direction takes only a moment to correct. This is the single decision that shapes everything else about the rest of the process, so it's worth pausing for a second to make sure you're not about to encode something that's already encoded.
- Paste your text. Enter the text you want to convert. For encoding, this is typically plain text containing spaces, punctuation, or non-Latin characters; for decoding, it's a percent-encoded string containing sequences like %20 or %3D that represent the original characters. Pasting text copied directly from a browser address bar, a server log, or an API response all work the same way, since the tool doesn't care where the input originally came from, only what it actually contains. The exact same input pasted twice in a row will always produce the exact same output, since this is a deterministic transformation with no randomness or external state involved anywhere in the process.
- Choose the encoding context if relevant. Some tools distinguish between encoding a full URL component versus encoding a value specifically meant for a query parameter, since a small number of characters (like the plus sign) are treated differently depending on context. Picking the wrong context for an unusual case can occasionally produce a result that looks correct but behaves subtly differently than intended. When in doubt, encoding for a query parameter value is usually the safer default, since it's the most common real-world use case and handles the characters most likely to cause trouble in practice. A few characters, including unreserved ones like letters, digits, hyphens, and periods, are never encoded under any standard scheme, since they're already considered safe to use directly within a URL.
- Review the result. Check that the converted output looks right — for encoding, confirm that spaces and special characters were properly converted to percent sequences; for decoding, confirm that the original readable text was correctly reconstructed without any leftover percent signs that should have been resolved. A quick visual scan against the original input, side by side, is usually enough to catch an obvious problem before the value gets used somewhere that's harder to debug after the fact.
- Copy the result into your URL or code. Copy the converted value directly into the URL, query string, or code where it's needed. Encoded values are safe to place directly into a URL path or parameter, while decoded values are what you'd display back to a human or process further in application logic. This final step is where the actual payoff happens — a correctly encoded value placed into a URL will survive being shared, clicked, and parsed by any browser or server without silently losing or corrupting any part of its content.
Use Cases
- Encoding a search query for a URL parameter: Encode user-entered search text containing spaces or special characters before appending it to a URL as a query parameter.
- Decoding a URL parameter to read its actual value: Decode a percent-encoded value found in a URL or server log to see what the original, readable text actually was.
- Debugging a broken link with special characters: Encode or decode a URL containing unusual characters to figure out why a link is being misinterpreted or truncated by a browser or server.
- Preparing a redirect URL with an embedded parameter: Encode a URL that needs to be embedded as a parameter value within another URL, such as a redirect-after-login target.
- Reading an encoded value from an API response: Decode a percent-encoded string returned in an API response or webhook payload to understand its actual content.
- Testing how special characters behave in a web form: Encode text containing edge-case characters to predict and verify how a web form or API will handle that input once submitted.
About This Tool
What is it? A browser-based tool that converts text to and from URL-safe percent encoding, handling the standard encoding rules used across browsers, servers, and JavaScript, without uploading anything to a server.
Why use it? It catches encoding mistakes before they reach production, where they typically only surface once a user enters a space, ampersand, or non-Latin character that breaks an improperly encoded URL.
Alternatives: JavaScript's built-in encodeURIComponent and decodeURIComponent functions handle this inside actual code, which is the right approach for production logic; this tool is for the many situations outside of code — debugging a URL by eye, checking a value from a log, verifying encoding before pasting into a browser — where running a script just for one value would be overkill.
Common mistakes: Double-encoding a value that's already encoded, turning a single percent sign into %25 and compounding the problem, is a common mistake when encoding is applied at multiple layers of an application without coordination; the second is assuming a URL with only simple ASCII text needs no encoding, which works until a user enters something with a space or special character that breaks it.
Frequently Asked Questions
- Is my text uploaded to a server during encoding or decoding?
- No, both operations happen entirely in your browser using JavaScript; nothing is transmitted anywhere.
- What does %20 mean?
- It's the percent-encoded representation of a space character — the percent sign followed by the character's hexadecimal code point.
- Why does a plus sign sometimes represent a space instead of %20?
- Within query string parameters specifically, a plus sign is also a valid way to represent a space, a legacy convention from form submission encoding, which is different from percent-encoding used elsewhere in a URL.
- What happens if I encode an already-encoded string?
- You get double-encoding, where the percent signs from the first encoding pass get encoded again, producing a string that needs to be decoded twice to recover the original text.
- Do I need to encode an entire URL, or just parts of it?
- Typically only the variable parts — query parameter values, path segments containing user input — need encoding; the fixed structural characters like slashes and the protocol shouldn't be encoded.
- Why does my decoded text still have percent signs in it?
- This usually means the string wasn't fully decoded, often because it was encoded more than once, requiring decoding to be applied more than once to fully recover the original text.
- Are non-English characters handled correctly?
- Yes, standard percent encoding handles any Unicode character by encoding its underlying byte representation, so accented letters, emoji, and non-Latin scripts all encode and decode correctly.
- Is there a difference between encodeURI and encodeURIComponent in JavaScript?
- Yes, encodeURI leaves characters that have meaning in a full URL (like slashes and colons) unencoded, while encodeURIComponent encodes those as well, since it's meant for encoding a single component like a parameter value.