URL Encoder / Decoder
Encode and decode URL components. Component mode encodes everything; URI mode preserves reserved characters like ? & /.
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.
| Character | Encoded | What happens if you leave it raw |
|---|---|---|
| space | %20 | Request may be truncated or rejected |
& | %26 | Value splits into an extra parameter |
= | %3D | Parameter parsing breaks at the wrong point |
? | %3F | Starts a query string where you meant data |
# | %23 | Everything after it is dropped before reaching the server |
+ | %2B | Read as a space in a query string |
/ | %2F | Reads as a path separator |
| non-ASCII | UTF-8 bytes, each percent-encoded | Mojibake, 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
- Encode each value separately, never the assembled URL.
- Join the encoded values with the raw separators: the ampersands and equals signs must stay literal.
- Include at least one value with a space, one with an ampersand and one with non-Latin characters in your test data.
- 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.