Skip to content

URL Encoder / Decoder

Encode and decode URL components. Component mode encodes everything; URI mode preserves reserved characters like ? & /.

Mode
INPUT
OUTPUT
Result will appear here

Percent encoding, and which characters actually need it

URL encoding replaces a character with a percent sign and its byte value in hexadecimal, so that characters with structural meaning in a URL can be carried as data. A space becomes %20, an ampersand becomes %26, a question mark becomes %3F. Without it, a value containing an ampersand splits into two query parameters and the request quietly means something else.

CharacterEncodedWhat happens if you leave it raw
space%20Request may be truncated or rejected
&%26Value splits into an extra parameter
=%3DParameter parsing breaks at the wrong point
?%3FStarts a query string where you meant data
#%23Everything after it is dropped before reaching the server
+%2BRead as a space in a query string
/%2FReads as a path separator
non-ASCIIUTF-8 bytes, each percent-encodedMojibake, or a rejected request

The hash is the one that surprises testers most. A fragment is never sent to the server at all, so a raw hash in a value means the server receives a truncated string and no error is raised anywhere.

encodeURI versus encodeURIComponent

JavaScript offers two functions and choosing wrongly is a reliable source of bugs. encodeURI is for a whole URL and deliberately leaves the structural characters alone, so it will not encode an ampersand or a slash. encodeURIComponent is for a single piece, one query value, one path segment, and encodes everything that is not unreserved.

The rule is simple: if you are encoding a value that goes into a URL, you want encodeURIComponent. If you are encoding an entire URL that is already assembled, you want encodeURI. Using the first on a complete URL destroys it; using the second on a value leaves the dangerous characters intact.

Why a plus sign sometimes means space

Two encodings coexist. In a query string submitted by an HTML form, a space is traditionally encoded as a plus, following the form-urlencoded rules. In a path segment, a plus is a literal plus. Whether a given server decodes a plus as a space depends on its framework and on which part of the URL the value sits in.

This is why an email address containing a plus, the tag addressing that testers use constantly, is one of the most productive test values there is. Send test+alpha@example.com as a query parameter and a surprising number of systems store it as test alpha@example.com, then fail to match it at login.

Finding double-encoding bugs

If a value arrives containing %2520, it was encoded twice: the percent of %20 was itself encoded to %25. Decode it once here and you will get %20 back rather than a space, which confirms the diagnosis immediately.

Double encoding usually happens when one layer encodes a value and a second layer encodes the whole URL again. It shows up as search terms that never match, redirect targets that fail, and filenames with visible percent codes. It is also a security-relevant case: filters that inspect a URL once can be bypassed by a payload that only becomes dangerous after the second decode, so double-encoded inputs belong in any input-validation test set.

Building query parameters for an API test

  1. Encode each value separately, never the assembled URL.
  2. Join the encoded values with the raw separators: the ampersands and equals signs must stay literal.
  3. Include at least one value with a space, one with an ampersand and one with non-Latin characters in your test data.
  4. Decode the value the server echoes back and confirm it round-trips exactly. A value that changes on the way through is a defect even when the response is 200.

Encoding and decoding both run in your browser, so query strings from an internal environment, which often carry identifiers and tokens, stay on your machine.

Frequently asked questions

What is the difference between URL encoding and HTML encoding?

They solve different problems. URL encoding uses percent sequences so characters can travel safely inside a URL. HTML encoding uses entities so characters can appear safely inside a document without being read as markup. Applying the wrong one leaves the original vulnerability open.

Should I use encodeURI or encodeURIComponent?

Use encodeURIComponent for individual values such as a single query parameter or path segment, and encodeURI only for a complete URL you have already assembled. Nearly every bug in this area comes from using encodeURI on a value.

Why does my URL contain %2520?

Because it was encoded twice. %2520 decodes once to %20 and only then to a space. Find the layer doing the second encode; it is usually a client that encodes a value and then encodes the whole URL again.

Do I need to encode characters in the path as well as the query?

Yes, with different rules. A slash in a path segment must be encoded or it creates a new segment, and a value containing a dot-dot sequence is a path traversal test case. The query string and the path have different reserved characters, so encode each part for its own context.

Is a space always encoded as %20?

In paths, yes. In query strings both %20 and + are seen, because form submissions historically used a plus. Servers usually accept either in a query, but only %20 is correct in a path.

Does URL encoding protect against injection?

No. It makes a value transport safely; it does nothing about how the value is used once decoded. SQL injection and cross-site scripting are prevented by parameterised queries and correct output escaping. Treat encoding as a transport concern only.