Percent-encoding is one of those things every engineer thinks they understand until they hand-write a URL with a + in the query string and watch it arrive on the server as a space. The rules for which characters are safe in which part of a URL are not symmetric — a character that’s fine in the path can break the query, a character that’s fine in a form-encoded body can break a header. Hand-rolling the encoding gets it wrong often enough that the right move is to stop guessing. PortJar’s URL Encoder / Decoder removes the guessing in one screen.
What the tool does
The tool takes any string and produces its percent-encoded form, or takes a percent-encoded string and produces the original. It runs entirely in your browser — nothing is sent to PortJar’s servers and nothing is logged. That matters when the string you’re encoding is a customer-supplied token, an internal identifier, or anything else you don’t want sitting in a third-party log.
Encoding follows the rules for the safe character set in URL components: alphanumerics, plus -, ., _, and ~ pass through, everything else becomes a %xx byte sequence in UTF-8. Decoding is the inverse — every %xx becomes the original byte, then those bytes are interpreted as UTF-8. Invalid sequences are flagged rather than silently mangled.
How to use it
Open portjar.com/tools/url-encoder. Paste the raw string into the encoder side to see its encoded form, or paste the encoded string into the decoder side to see what it actually represents. The conversion is live — what you paste is what gets converted, and you can copy the result straight out without an extra round-trip through a shell or scratch file.
When you’d reach for it
- Building a URL with a non-ASCII parameter. A French accent, a Cyrillic name, an emoji in a search term — any of these will break a URL if you paste them in raw. Encoding the value first guarantees the receiving server gets the bytes you meant.
- Decoding a query parameter pasted from a log line. Access logs preserve the encoded form. When you want to know what a request was actually asking for, the decoder turns
%2Fadmin%2Fusers%3Fid%3D42into/admin/users?id=42in one paste. - Catching a double-encoding bug. When a value looks like
%2520instead of%20, it was encoded twice — most often by a framework that already encoded the value and then re-encoded the URL containing it. The decoder makes the double layer obvious, because decoding once gives you%20and decoding again gives you a space. - Constructing a signed URL by hand for a one-off test. When you need to mock a signed URL against a service that hasn’t been wired into the deploy pipeline yet, the encoder produces the exact byte sequence the signer expects.
- Reading a suspicious URL from a phishing or security alert. Attackers obfuscate destinations with extra encoding to bypass URL filters. Decoding the URL before clicking — or before allowing anyone else to click — turns the obfuscation into plain text you can evaluate.
What to make of the output
A round-trip — encode, then decode — should return exactly what you started with. If it doesn’t, the input had a character the tool flagged, or it had encoded bytes that didn’t form valid UTF-8. Both are worth investigating before you ship the URL anywhere.
Watch the space. A literal space encodes to %20 in a URL path or query value. The legacy form-encoded convention represents space as +, which is what application/x-www-form-urlencoded bodies use. The two are not interchangeable in a URL — a + in a query value is meant as a space by some receivers and as a literal + by others, and the disagreement is a frequent source of bugs. When in doubt, use %20.
Watch the slashes. A / in a URL path is a path separator. A %2F is the literal slash character and is not interpreted as a separator — some web servers will reject the request outright (AllowEncodedSlashes off on Apache, similar on nginx), and others will accept and pass it through. If a value you’re encoding contains a slash, that slash is almost always meant to be encoded, but the receiving server needs to be configured to accept it.
Watch the question mark and the ampersand. A ? is the query separator and an & separates query parameters. Both must be encoded if they appear inside a value, otherwise the receiver will read them as structural and parse the URL wrong.
A surprise byte after decoding — control characters, a null, a UTF-8 sequence that doesn’t form a sensible glyph — is often the most useful finding the tool produces. It’s the moment you realise the URL was carrying something the system that produced it didn’t intend.
For environments where URL handling, form encoding, and certificate hygiene need to stay consistent across many sites, Stack Harbor handles that as part of Environment Management as a Service.