URL Decoder and Encoder

A free, in-browser tool that decodes and encodes URL percent-encoding with full charset control. Paste a single URL or a whole column of them, switch between UTF-8, Latin-1, and Windows-1251, and watch the output update as you type.

Open the URL Decoder

What it does

The tool performs two complementary operations on URLs and URL fragments.

Decoding converts percent-encoded byte sequences back to the characters they represent. %20 becomes a space. %3D becomes =. %E2%9C%93 becomes the check-mark character. Decoding is the operation you need when you are reading something — a logged URL, a redirect chain, an analytics query string — and you want to see what the original input actually was before percent-encoding hid it.

Encoding goes the other way. Given a string that contains characters that are not safe in a URL, the tool replaces them with percent-encoded equivalents under the charset you choose. This is the operation you need when you are building a URL programmatically and want to test how a specific input will be encoded before you ship code that depends on it.

Both modes support a per-line batch mode: paste a list of URLs, get a list of decoded or encoded URLs back, in the same order. That matters when you are processing a column from a log dump or a CSV.

Who it's for

Web developers debugging redirects, OAuth flows, deep links, or any URL that gets passed through several systems before reaching its destination.
Analytics and marketing engineers inspecting tracking parameters, UTM tags, and campaign URLs — especially the ones that round-trip through a third-party tag manager and come out double-encoded.
Security researchers and pentesters looking at logs, payloads, and parameter values that have been deliberately obfuscated with multiple layers of percent-encoding.
Localization engineers who deal with URLs containing non-ASCII characters (Cyrillic, Greek, accented Latin) and need to understand why a server is decoding them as garbage.
Ad-tech engineers reading impression URLs, click trackers, and macro-expanded creative links from bid responses.

When to use it

Decoding redirect URLs. An auth provider redirects to https://app.example.com/callback?return_to=https%3A%2F%2Foriginal.example.com%2Fpath%3Fq%3D1. Decode it to see exactly where the user came from.
Debugging analytics parameters. Your utm_content shows up wrong in a report. Was it encoded once, twice, or three times? Decoding repeatedly until the output stops changing tells you.
Batch processing log files. Pull a column of URLs out of a log, paste it in per-line mode, and get a clean column back.
Validating manually constructed URLs. Building a URL in code? Paste the unencoded raw string with the special characters you intend, encode it, and confirm the output matches what your code produces.
Investigating legacy systems. Old web apps sometimes emitted URLs in non-UTF-8 charsets — Windows-1251 was common in Eastern European systems. When a modern decoder produces garbage, switching the charset usually fixes it.

Features

Feature	What it does
Decode and encode modes	A single switch toggles the direction. The input stays the same; the output updates.
Three charsets	UTF-8 (default, correct for modern web), Latin-1 / ISO-8859-1 (for very old systems and some legacy email tools), Windows-1251 (Cyrillic-script legacy systems).
Per-line input mode	Treats each line as an independent URL. Encodes or decodes each one separately. Blank lines are preserved so column alignment with another data source is intact.
Live preview	The output area refreshes as you type. Turn off for very large batches.
Component-aware mode	Optional. Decode or encode just the query string, just the path, or the full URL. Different RFC rules apply to each component.

How URL encoding actually works

URL encoding is governed by RFC 3986 ("Uniform Resource Identifier: Generic Syntax"). The rules are deceptively simple, and almost every "broken URL" bug comes from a place where someone applied them inconsistently.

Reserved versus unreserved characters

RFC 3986 splits printable ASCII into a small set of unreserved characters that are always safe in a URL — letters, digits, and the four symbols -, ., _, ~ — and a larger set of reserved characters that have syntactic meaning (/, ?, #, &, =, +, and friends). Anything else — spaces, punctuation outside the safe set, all non-ASCII — must be percent-encoded.

Why `+` sometimes means space

In the path component of a URL, + is just a literal plus sign. In the query component, by long-standing convention inherited from HTML form submissions, + is treated as an encoded space. That single rule difference between components causes a remarkable number of bugs. The tool's component-aware mode applies the right convention for whichever component you tell it you are working with.

Non-ASCII characters

The original RFC predates Unicode and treats URLs as ASCII-only. Modern practice (RFC 3987 and the WHATWG URL Standard) is to UTF-8-encode the Unicode character to a byte sequence, then percent-encode each byte. Older systems often used a different encoding — Latin-1 for Western European content, Windows-1251 for Cyrillic, Shift-JIS for Japanese — and produced percent-encoded URLs that only decode correctly under that specific charset.

Common pitfalls

Double encoding

The classic. You encode once, then a framework or middleware encodes again, and you end up with %2520 (which is the percent-encoding of %20, which itself is the percent-encoding of a space). Decoding once produces %20 instead of a space. The fix is to decode repeatedly until the output stops changing — then count how many times you had to decode, and look upstream for where the second encoding crept in.

Charset mismatch

The bytes %E1 mean different things in different charsets. In UTF-8 it is the lead byte of a three-byte sequence (and produces garbage on its own). In Latin-1 it is the lowercase letter "a with acute accent." In Windows-1251 it is the Cyrillic letter "б." Decoding the same input under the wrong charset gives you garbage — usually a question mark, a replacement character, or a misleading-looking ASCII fragment.

Forgetting to encode the ampersand

When a query parameter value itself contains an &, the ampersand has to be encoded as %26 or the URL parser will treat it as a parameter separator. Build URLs with a library that knows this, not by string concatenation.

Encoding the wrong characters

Some encoders are overly aggressive and encode characters that did not need encoding — / inside a path, for example. The result is still valid, but harder for humans to read and sometimes a source of cache-key drift.

Frequently asked questions

When do I need Windows-1251?

Mostly when you are reading logs from older systems that handle Cyrillic content — Russian, Ukrainian, Bulgarian, Serbian — and predate the universal move to UTF-8. Some legacy CMS and email-tracking systems still emit URLs encoded that way. If a decoded URL contains question marks where Cyrillic letters should be, switching the charset to Windows-1251 usually produces readable text.

What is the difference versus `encodeURIComponent` in JavaScript?

encodeURIComponent is the closest standard-library equivalent of what the encode mode does. There are two practical differences. First, this tool lets you choose a charset other than UTF-8; encodeURIComponent is always UTF-8. Second, this tool can run in component-aware mode so it respects the different reserved-character rules for path versus query versus fragment, whereas encodeURIComponent applies one fixed rule.

Does it handle data URIs?

Yes, with one caveat. A data URI like data:text/plain;base64,SGVsbG8= is a URL whose "content" is the payload after the comma. The tool will decode percent-encoded characters in the URL as normal, but it does not decode the base64 payload itself — that is a separate operation. Use a base64 decoder for that step.

Can it handle very long URLs?

Yes. There is no hard length limit beyond browser memory. Per-line mode comfortably handles a few thousand URLs per paste in modern browsers.

Does the tool send my URLs anywhere?

No. Decoding and encoding are pure string operations that run in your browser. Open DevTools and confirm there are no outbound requests beyond the static assets that loaded the page itself.

Why does encoding the same string twice give a different result?

It does not — encoding is idempotent for well-formed unencoded input. What people usually hit is that they encode an already-encoded string, which produces a different result because the percent signs themselves get encoded. If you want to double-check, decode first until the output stabilizes, then encode once.