Free URL Encode/Decode Online

URL encode/decode converts characters that aren't safe inside a URL — spaces, ampersands, question marks, non-Latin text — into a percent-sign-prefixed hex sequence, and reverses that same substitution to get the readable string back. Anyone who builds request URLs, debugs a webhook payload, or has ever wondered why a redirect link with a space in it silently truncated has run into this. This guide walks through what percent-encoding actually does, the practical difference between encoding a whole URL and encoding a single value that goes inside one, and where a browser-based tool fits next to the encoding functions already built into every language.

How the URL Encode/Decode Tool Works

The tool is built around two linked text areas rather than a single input/output pair, because in practice people go back and forth between encoded and decoded forms while debugging:

• Type or paste plain text or a URL into the Decoded box, and the Encoded box updates automatically — or paste an already-encoded string into the Encoded box and the Decoded box fills in the reverse.
• Toggle between encodeURIComponent and encodeURI using the buttons above the text areas. This choice matters more than it looks — the two functions escape a different set of characters, covered in detail below.
• If what you pasted is a full, valid URL, a URL Breakdown panel appears automatically, splitting it into protocol, host, port, path, fragment, and each individual query parameter as a separate key-value row.
• Use the Query String Builder at the bottom to add key/value pairs one at a time and generate a correctly encoded query string without hand-typing percent signs — useful when you're assembling a URL with parameters that themselves contain spaces or special characters.
• Copy either pane's contents independently using the copy icon next to each box.

This is a text-in, text-out tool — there's no file upload, and nothing is batched. For scripts, build pipelines, or anywhere you need URL encode/decode logic outside a browser tab, the same conversion is available as an API endpoint documented at /docs.

When You Need to Percent-Encode or Decode a URL

Percent-encoding isn't just a formatting nicety — URLs have a strict grammar, and characters outside it will break parsing or get silently mangled somewhere along the request path. Common situations:

• Building API request URLs by hand. A query parameter containing a space, an ampersand, or a plus sign will be misread as a parameter separator or literal plus if it isn't encoded first, silently corrupting the request instead of throwing an obvious error.
• Passing redirect URLs as a parameter. OAuth callback flows and many redirect-based integrations pass a full URL as the value of another URL's query parameter. That inner URL has to be encoded, or its own ? and & characters will be parsed as part of the outer URL instead of as an opaque value.
• Debugging a URL pulled from logs. Server logs and browser network panels often show URLs in their encoded form. Decoding one is usually the fastest way to see what a user actually searched for, what path was requested, or what value a broken integration actually sent.
• Handling non-ASCII text in a URL. A search query, filename, or user-entered string containing accented letters, Cyrillic, Chinese characters, or emoji needs percent-encoding before it's URL-safe, since URLs are technically restricted to a limited ASCII character set.
• Sharing links that contain special characters. A file path or search term with spaces, quotes, or brackets in it needs those characters encoded before the link can be reliably clicked, pasted, or embedded elsewhere without breaking.
• Reconstructing a query string for testing. When you need to hand-build a request with several parameters for a manual test or a Postman collection, the Query String Builder produces the exact encoded string without needing to work out percent codes for each special character by hand.

Percent-Encoding Explained: Reserved Characters and the Component/URI Split

Percent-encoding replaces a byte with a percent sign followed by two hex digits representing that byte's value — a space becomes %20, an ampersand becomes %26, and so on. Any byte outside a small set of characters considered always-safe (letters, digits, and a handful of symbols like -, _, ., and ~) is a candidate for encoding, depending on where in the URL it sits.

That last part — where in the URL it sits — is exactly the distinction between the tool's two encoding modes:

• encodeURIComponent is the aggressive option, meant for encoding a single value that will be placed inside a URL — a query parameter, a path segment. It escapes everything that isn't a letter, digit, or one of a few safe symbols, including characters that have structural meaning in a URL like &, =, ?, and /. Use this whenever you're encoding one piece of data to insert into a larger URL.
• encodeURI is the gentler option, meant for encoding an entire URL that's already assembled. It leaves structural characters like :, /, ?, &, and = untouched, since those are doing their normal job of separating the protocol, path, and query string. It only encodes characters that shouldn't appear in a URL at all, such as spaces or non-ASCII text.

Mixing these up is a common source of bugs: running encodeURIComponent on a full URL turns its own :// and ? into garbage, while running encodeURI on a single parameter value leaves characters like & unescaped, so a value such as tom & jerry ends up looking like two separate parameters instead of one string.

Character	encodeURIComponent	encodeURI
Space	%20	%20
&	%26	& (unchanged)
=	%3D	= (unchanged)
/	%2F	/ (unchanged)
?	%3F	? (unchanged)
:	%3A	: (unchanged)

One more honest nuance worth knowing: the + character has a special legacy meaning specifically inside a query string, where it's historically been treated as an encoded space by many server frameworks — a convention from HTML form submission, not from the core URL specification. Neither encodeURIComponent nor encodeURI produce a literal + for a space (they both use %20), so if you're decoding a query string from an old form submission and see a plus sign that should be a space, that's a framework-level convention this tool's standard percent-decoding won't automatically apply.

It helps to think of the safe characters in two groups. Unreserved characters — letters, digits, -, _, ., and ~ — are never encoded by either function, because they carry no special meaning anywhere in a URL. Reserved characters — things like :, /, ?, #, &, and = — are the ones that separate a URL into its parts, and whether they get encoded depends entirely on whether you're treating the string as a complete URL or as one value that happens to be going inside a URL. That's the whole reasoning behind having two modes instead of one: a reserved character sitting inside a parameter value needs to be encoded so it isn't mistaken for structure, while the same character sitting in its normal structural position needs to stay exactly as it is.

URL Encode/Decode vs Other Methods

Several tools solve the same problem, each suited to a different point in the workflow:

• curl's --data-urlencode flag. When you're already building a curl command, this flag handles the encoding inline without a separate step. It's efficient for that specific case but isn't useful for inspecting or debugging an existing encoded string.
• Language-level functions. Python's urllib.parse.quote, Node's built-in encodeURIComponent, and similar functions in every mainstream language are the right call when encoding is one line inside a larger program rather than a manual task.
• Postman or an API client. These often encode query parameters automatically when you fill in a form field, which is convenient during API testing but doesn't help when you need to manually inspect or construct an encoded string outside that tool.
• An online URL encode/decode tool. No terminal, no script — paste a string in either direction and get the encoded or decoded result immediately, plus a structural breakdown of a full URL's components in one place. It's built for manual, one-off lookups and debugging rather than encoding thousands of values in a batch, which is what the API or a language library is for.

How Your Data Is Processed

Encoding and decoding both run entirely in your browser using JavaScript's native URI functions — nothing you type or paste is sent to a server. This is worth knowing because URLs often carry more than they look like they do: session tokens in query parameters, internal API paths, or search terms tied to a specific user. Since the conversion happens client-side, none of that data leaves your machine as part of using the tool.

Common URL Encoding Questions

What's the actual difference between encodeURIComponent and encodeURI?

encodeURIComponent escapes nearly every non-alphanumeric character, including ones that have structural meaning in a URL like & and =. encodeURI leaves those structural characters alone and only escapes characters that shouldn't appear in a URL at all. Use encodeURIComponent for a single value going into a URL, and encodeURI for a complete URL you're encoding as a whole.

Why did decoding a query string leave plus signs instead of spaces?

Standard percent-decoding only converts %XX sequences back to characters — it doesn't know about the older, form-submission-specific convention where + represents a space in a query string. That convention comes from HTML forms and web frameworks, not from the URL specification itself, so a generic decoder won't apply it automatically.

Can I encode an entire URL, query parameters and all, in one step?

You can, using encodeURI mode, but it will leave the URL's own structural characters like & and = untouched by design — which is usually what you want when the string is already a complete, correctly structured URL, rather than a single value being inserted into one.

Why does my parameter value need encoding if it displays fine in the browser?

Modern browsers are forgiving and will often display or even auto-correct an unencoded URL for readability. The server or API receiving the request may not be as forgiving, and un-encoded special characters can be split, truncated, or misinterpreted as separate parameters once the request actually leaves the browser's address bar.

Does this tool handle Unicode characters in URLs correctly?

Yes. Non-ASCII characters — accented letters, Cyrillic, CJK text, emoji — are percent-encoded based on their UTF-8 byte representation, matching how modern browsers and servers handle internationalized URLs, and decoded back to the original characters in reverse.

Related Tools

If the value you're encoding is a token or credential rather than a URL fragment, Base64 Encode/Decode handles that different encoding scheme — the two are easy to confuse but solve different problems. Query strings that carry a JSON payload as one parameter often need JSON Formatter afterward to make the decoded value readable. If you're inspecting a redirect URL that carries an authentication token, JWT Decoder can parse it once it's been extracted from the query string. For building a URL list for search engines rather than debugging individual links, Sitemap XML Generator covers that adjacent task. And for encoding or decoding URLs as part of an automated pipeline instead of a manual paste, the same logic is available through the metered API — details at /docs.