URL encode and decode text

What percent-encoding does

A URL can only carry a limited set of characters, and some of those have jobs: ? starts the query, & separates parameters, = joins a name to its value, # starts the fragment and / separates path segments. Anything else, and any of those characters used as plain data, is written as a percent sign followed by two hex digits for each byte.

Letters, digits and - _ . ~ are never encoded. Like the encodeURIComponent function browsers use, Octoolo also leaves ! * ' ( ) alone, since URLs allow them.

One value or a whole address: the switch that matters

The most common URL-encoding bug is encoding the wrong amount.

• A value going into a URL (switch off). Searching for fish & chips? The value must become fish%20%26%20chips, so the & is not read as the start of another parameter. The same goes for a whole link passed as a parameter, like a return_url or a redirect_uri: as a value, https://example.com/?q=1 becomes https%3A%2F%2Fexample.com%2F%3Fq%3D1.
• A whole address (switch on). Here the : / ? & = have to stay, or the link stops working. Only spaces and non-ASCII letters are encoded, so https://example.com/a b?q=café&x=1 becomes https://example.com/a%20b?q=caf%C3%A9&x=1.

Encode a whole address with the switch off and you get one long string no browser can open. Encode a value with it on and any & or = inside the value slips through and breaks the parameters. When you build a URL by hand, encode each value on its own, then join the pieces.

Decoding, plus signs and double encoding

Decoding reverses it: each %XX sequence is read as UTF-8 and turned back into its character. Octoolo also turns + into a space, because HTML forms and many analytics tools write spaces that way (the application/x-www-form-urlencoded format). A real plus sign in data should arrive as %2B, which decodes to + as it should. A literal + in a path, as in some file names, will come back as a space.

If the result still contains %20 or %3A, the text was encoded twice. %2520 is a % (which itself encodes to %25) followed by 20. Decode again until the percent signs are gone. This happens a lot with redirect links that pass through several services, each adding a layer.

A % that is not followed by two hex digits, or bytes that do not form valid UTF-8, stop decoding with "This text has a broken % sequence." Look for a lone % in the text, such as 50% off, which should have been encoded as 50%25.

Other ways to do it on Windows

PowerShell has both directions built in. [uri]::EscapeDataString("fish & chips") encodes a value, the same as the switch-off mode here, and [uri]::UnescapeDataString() decodes. [System.Net.WebUtility]::UrlDecode() decodes and also treats + as a space. In Excel, the ENCODEURL function encodes a cell's text for use in a query string. Browsers do some of it for you: the address bar shows accented letters as letters, but copying the address gives you the encoded form, which is why a pasted link can look different from the one you saw.

Those suit scripts. For reading a messy tracking link, an OAuth redirect or a log line with nested encodings, a live two-pane view is quicker: paste, read, decode again if needed. When the text you are pulling apart turns out to be a token, hand it to the JWT decoder or Base64. For clean addresses made of words and hyphens, Text Studio has a slug generator.