URL Encoder Decoder — percent-encode or decode any string

A URL encoder decoder converts text between its plain form and percent-encoding — the %XX escape sequences that let a URL safely carry characters like spaces, ampersands, and non-ASCII letters that would otherwise break the URL's structure or get mangled by whatever's transmitting it. If you've ever seen %20 where a space should be, or wondered why an & in a search term suddenly split your query string into pieces, you've run into exactly the problem this tool exists to solve, in both directions.

This tool encodes or decodes any text or URL locally in your browser, and — critically — it makes the distinction between encoding a whole URL and encoding a single component explicit, because picking the wrong one is one of the most common silent bugs in web development. Arb Digital's engineers build and debug URLs, query strings, and redirects constantly, and getting this distinction right the first time saves a lot of head-scratching later.

What This URL Encoder Decoder Does

Paste text or a URL into the input box, choose Encode or Decode, choose whether you're working with a whole URI or a single component, and click Convert. In encode mode, the tool runs your input through JavaScript's native encodeURI() or encodeURIComponent() depending on the scope you pick, converting unsafe or reserved characters into their percent-encoded form. In decode mode, it runs the corresponding decodeURI() or decodeURIComponent() function, turning percent-encoded sequences back into readable characters. The result appears instantly in a copyable output box, along with a quick comparison of input and output length so you can see at a glance how much the string actually changed.

How to Use It

1. Paste your text or URL. It can be plain text you want to make URL-safe, or an already-encoded string you want to read.
2. Pick Encode or Decode. Encode turns readable text into percent-encoded form; Decode reverses it.
3. Pick the scope. Component treats reserved characters like &, =, and ? as things to encode — correct for a single query parameter's value. Whole URI leaves those characters alone because they're structurally meaningful in a full link.
4. Click Convert. The result appears immediately in the output box below.
5. Copy and use it. Grab the result with the Copy button and drop it wherever it needs to go — a query string, an API call, a redirect config.

How Percent-Encoding Works

A URL is technically limited to a specific set of ASCII characters — letters, digits, and a handful of punctuation marks like -, _, ., and ~ that are considered always safe. Everything else — spaces, non-ASCII letters and emoji, and "reserved" punctuation like &, =, ?, /, and # that has special structural meaning in a URL — has to be represented differently to travel safely. Percent-encoding does this by taking each problem character's byte value (using UTF-8 for anything beyond plain ASCII) and writing it as a percent sign followed by two hexadecimal digits — a space becomes %20, an ampersand becomes %26, and so on. This is why an emoji or an accented letter typed into a search box turns into a long string of %XX sequences once it lands in the address bar. The full rules for which characters are reserved, unreserved, or need escaping are defined by the URI specification, RFC 3986, and JavaScript's implementation is documented at MDN's encodeURIComponent() reference.

encodeURIComponent vs encodeURI — the Distinction That Actually Matters

This is the single most important thing to understand about URL encoding, and it's the source of a huge share of real-world query string bugs. encodeURIComponent() encodes every character that isn't in its small "always safe" set, including the reserved characters &, =, ?, /, and # — because those characters have no structural meaning inside a single value, and if your value happens to contain a literal & or =, it absolutely needs to be encoded, or it will be misread as a delimiter between separate parameters. Use encodeURIComponent() whenever you're encoding one piece that's going to be inserted into a larger URL — a query parameter's value, a path segment, a hash fragment's content.

encodeURI(), by contrast, assumes you're handing it an entire, already-structured URL, so it deliberately leaves the reserved characters — &, =, ?, /, #, : — untouched, because encoding them would break the URL's own structure by turning a real query separator into a literal character. It still encodes spaces and non-ASCII characters, just not the punctuation that gives the URL its shape. Using encodeURI() on a single query value is a mistake, because any & or = inside that value won't get encoded and will silently corrupt your query string, splitting it into parameters you didn't intend. Using encodeURIComponent() on a whole URL is an equally common mistake in the other direction — it will also encode the ://, the ?, and the & that are supposed to remain as structural URL syntax, turning a working link into a single unusable blob of percent-encoded text. Match the function to what you're actually encoding, and this entire class of bug disappears.

The Double-Encoding Trap

A second common bug is encoding something that's already encoded. If a value has already been through encodeURIComponent() once and you run it through the same function again, every % character from the first pass — which is itself not a URL-safe character — gets encoded again into %25, turning %20 into %2520. The result still technically decodes, but only if it's decoded twice, and most systems decode exactly once, so a double-encoded value shows up looking wrong — literal percent signs and digits where a space or symbol should be. This tends to happen when encoding logic exists in more than one layer of an application — a frontend that encodes a value before sending it, and a backend or framework that encodes it again before using it — without either layer being aware of the other. If you're debugging a URL that looks like it has stray %25 sequences, decoding it once first to see if a normal-looking encoded string appears is a fast way to confirm double-encoding is the culprit.

Reserved vs Unreserved Characters

The URI specification splits characters into two buckets, and understanding the split explains why encoding behaves the way it does. Unreserved characters — uppercase and lowercase letters, digits, and the four punctuation marks -, ., _, and ~ — are always safe to leave alone in any part of a URL, and no encoding function will ever touch them. Reserved characters — things like :, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ,, ;, and = — are the ones with structural meaning: they separate the scheme from the host, the path from the query string, one parameter from the next. Whether a reserved character needs encoding depends entirely on context — a / is essential structure in a path but meaningless (and therefore unsafe to leave raw) inside a single filename that happens to contain one. This context-dependence is exactly why there are two different encoding functions rather than one: encodeURI() assumes you're handing it a complete, already-structured URL and preserves reserved characters as structure, while encodeURIComponent() assumes you're handing it one isolated piece and treats every reserved character as literal data that needs escaping so it can't be misread as structure.

What Happens Behind the Scenes When You Type a URL

Every time you type a search term with a space or an accented character into an address bar, your browser is quietly doing the same percent-encoding this tool does explicitly. That's part of why copying a link out of a browser sometimes gives you a long string of %XX sequences even though you originally typed something perfectly readable — the browser encoded it before sending the request, and depending on the browser and site, that encoded form is what ends up in the address bar and in anything you copy from it. Servers reverse the process on the way in: a web framework decodes the query string and path before handing your code readable parameter values, which is why application code almost never needs to manually decode incoming request data — the framework already did it — but frequently does need to manually encode outgoing values before building a link or a redirect. Understanding this round trip is useful when you're debugging why a URL you built by hand doesn't behave the way one generated automatically by a framework does: the manual version is missing an encoding step the framework normally handles for you.

When to Reach for This Tool

• Debugging a broken query string. Decode it to see exactly what's being sent, or encode a suspect value to confirm it's the one causing the split.
• Building a URL by hand. Encode dynamic values before concatenating them into a link, especially anything containing user input.
• Reading a log or redirect URL full of %XX sequences. Decode it back to plain text to actually understand what it contains.
• Preparing a value for an API call. Many APIs expect query parameters to be properly component-encoded before they're appended to the request URL.

Common Mistakes to Avoid

• Using encodeURI() on a single query value. It won't encode & or =, so a value containing either will corrupt your query string.
• Using encodeURIComponent() on a full URL. It will over-encode the structural characters and break the link entirely.
• Encoding a value twice. Watch for stray %25 sequences — a sign the value already went through encoding once before reaching your code.
• Forgetting that plus signs and spaces aren't interchangeable everywhere. Some legacy form-encoding contexts use + for a space instead of %20 — the two are not the same thing in every context.
• Assuming decoding always succeeds. A malformed percent sequence (like a stray % not followed by two hex digits) will throw an error in decodeURIComponent() rather than silently passing through.

Related Free Tools From Arb Digital

URL encoding often comes up alongside other data-formatting tasks. Try our Base64 Encoder/Decoder for a different kind of safe-transport encoding, the JSON Formatter for cleaning up API payloads, the JWT Decoder for tokens that often travel inside URLs, and the Hash Generator for generating checksums. Explore every tool we've built in the free online tools hub.

Frequently Asked Questions