Free

URL Encoder and Decoder

Percent-encoding in both directions, with the three encodings most tools collapse into one kept separate - and the URL broken into its parts so you can see where the problem actually is.

  • Free forever
  • No signup
  • Runs in your browser

At a glance

Takes
A URL, a query-string value, or anything already encoded
Returns
The encoded or decoded string, plus the URL’s parts and parameters
Handles
Component, full-URL and form encoding, and flags double-encoding
Privacy
Runs in your browser - nothing you paste is uploaded

Nothing you type leaves this page

This tool runs entirely in your browser. Nothing you type or paste is sent to Revquix or to anyone else, no account is needed, and the page keeps working with your network disconnected.

Full detail in our privacy policy and AI policy.

How this works

About URL Encoder

What it checks, what it deliberately does not, and how to read the output.

Three encodings, and why offering one is wrong

This is where most tools quietly mislead. Percent-encoding is not a single operation, and picking the wrong one of the three is usually the bug that brought you here.

Component encoding escapes everything structural - ampersand, equals, question mark, slash, hash - and is what you want for a single value going into a query string. Full-URL encoding deliberately leaves those alone, because escaping the slashes in a scheme produces something that is no longer a URL. Form encoding is component encoding with space as plus rather than percent-twenty, which is what HTML forms and most HTTP clients send by default.

The last one is not interchangeable with the others. In form encoding a literal plus decodes to a space, so round-tripping a value through the wrong mode silently corrupts any plus sign in it - a base64 payload in a query parameter is the usual casualty.

Double-encoding, named

A percent-twenty-five-twenty in a production URL means a percent sign was itself encoded: the value went through an encoder twice, almost always because one layer encoded something that arrived already encoded. The decoder flags that pattern explicitly rather than leaving you to notice that decoding twice gives a different answer.

Alongside it, the tool splits the URL with the platform’s own parser and lists the query parameters decoded, so you can see the values as the server will receive them rather than as they appear on the wire.

Strict mode, and who needs it

The standard component encoder leaves exclamation marks, apostrophes, parentheses and asterisks unescaped. That is fine almost everywhere and fatal in two places: OAuth 1.0a signature base strings and AWS Signature Version 4 both require them escaped, and a mismatch there produces a signature failure with no other symptom. Strict mode escapes them.

What this does not do

Percent-encoding is not HTML escaping and it is not encryption. It makes a string safe to put in a URL; it does nothing about cross-site scripting, and it conceals nothing from anybody, since any parser reverses it trivially.

It also cannot tell you which layer of your stack applied an encoding. The tool shows what each mode would produce; deciding which part of the request path did it is still yours.

FAQ

Questions people actually ask

The ones that come up before somebody uploads anything.

Why did my plus sign turn into a space?

Because you decoded with form encoding, where a plus means a space. That is correct for anything from an HTML form or a typical query string, and wrong where the plus is literal - a base64 payload, for instance. Switch to component mode and the plus survives the round trip.

Should I use component or full-URL encoding?

Component for a value going inside a URL, full-URL for a whole address. Encoding an entire URL with component mode escapes its slashes and colon - correct when you are putting one URL inside another as a redirect parameter, and wrong when you meant to make the URL itself safe to use.

What does a percent-twenty-five in my URL mean?

That a percent sign was encoded, which means the value went through an encoder twice. A space encodes to percent-twenty; encoding that percent gives percent-twenty-five-twenty. It is almost always a layering bug where something encoded a value already encoded upstream, and the tool flags the pattern when it appears.

Is percent-encoding a security measure?

No. It is a transport rule that makes a string safe inside a URL, and it hides nothing. It is not a defence against cross-site scripting either - that needs contextual escaping at the point of output, which is a different operation applied in a different place.

Why does strict mode escape apostrophes and asterisks?

Because the standard encoder leaves them alone and two widely-used signing schemes do not. OAuth 1.0a and AWS Signature Version 4 both build a canonical string that requires those characters escaped, and if yours are not, the signature will not match - with no error that says so.

Next, try one of these

More from Developer, or browse the full catalogue.

When the encoding is not the bug

A broken query string is usually a boundary problem

Something in your stack is encoding a value that arrived already encoded, or decoding one that should have stayed opaque. Working out which layer owns that is a design question rather than a string question, and an hour with a senior engineer on the request path is the short way to it.

Talk to an engineer from ₹549/hr