Spaces came out as %20; I expected plus signs.

Plus is the form-encoding convention for spaces in application/x-www-form-urlencoded bodies. In a URL component %20 is the correct form, and most servers accept either.

Can I decode instead?

Yes, the Base64 and URL tool linked from the second step has a decode mode; the cleaning step is not needed for that direction.

Clean text and URL-encode it

2 min readLast updated 12 September 20262 steps · runs on this page

A search term, a redirect target or a filename pasted into a URL needs percent-encoding, and if it was copied from a document it may also contain characters that encode correctly and still break the request. The recipe cleans first and encodes second.

The steps

1
Clean hidden charactersvia Invisible Character Detector
Curly quotes become straight ones, zero-width characters and non-breaking spaces are removed; these encode to valid but wrong sequences.
2
URL encodevia Slug / URL Encoder
Percent-encodes everything outside the unreserved set, including spaces, ampersands, slashes and non-ASCII letters.

Value for a query string

Ctrl+Enter runs · nothing leaves this tab

What gets encoded

Letters, digits, hyphen, underscore, full stop and tilde pass through. Everything else becomes a percent sign and two hex digits per UTF-8 byte: a space is %20, an ampersand %26, a slash %2F, and é is %C3%A9. The whole value is encoded as one component, so an ampersand inside it will not be mistaken for a separator between parameters.

Why cleaning matters more here than usual

A zero-width space encodes to %E2%80%8B, which is valid, invisible in the decoded value and enough to make a search return nothing or a lookup miss its key. A non-breaking space becomes %C2%A0 rather than %20 and is not treated as a space by the receiving side. Curly quotes are less harmful but produce different results from the straight ones the user typed. Cleaning first removes a class of bug that is otherwise very hard to see.

Checking the result

Paste the encoded value into the URL parser with the rest of the address around it to see it decoded back into parameters. If the decoded value is not what you started with, something in the destination is decoding twice or not at all, which is a common cause of plus signs and percent signs multiplying in redirects.

Questions

Spaces came out as %20; I expected plus signs.: Plus is the form-encoding convention for spaces in application/x-www-form-urlencoded bodies. In a URL component %20 is the correct form, and most servers accept either.
Can I decode instead?: Yes, the Base64 and URL tool linked from the second step has a decode mode; the cleaning step is not needed for that direction.