Percent-encode or decode URL components with the right rules per part of the URL.
Tools for engineers who would rather not context-switch into yet another tab to validate a JWT or generate a UUID. Everything runs in your browser, your payloads never leave the machine, and the pages load fast enough that you can leave them open in a sidebar while you debug.
Encodes path, query, or full URL separately - because each part of a URI has different reserved characters, and using one mode for all of them is the most common encoding bug.
Decodes percent-escapes and renders the result so you can see what the receiving server will actually receive.
Round-trips safely through both encodeSpacePlus-style form encoding and the stricter RFC 3986 percent encoding.
How to use it
Paste the URL or component. Pick the mode that matches the part of the URI you are working with.
If you are debugging a 400 from a third-party API, decode their query string and you will often spot the unencoded character that is breaking parsing.
Copy the encoded version back into your code, your curl, or your redirect target.
Which characters actually have to be encoded in a query parameter?
The reserved ones that would otherwise read as syntax: & separates parameters, = separates name from value, # starts the fragment, and + means a space in form encoding. Anything you cannot see - spaces, quotes, non-ASCII - has to be encoded too.
Why does my value change when it arrives at the server?
Either it was encoded twice, so the receiving side decodes once and leaves your %2B on display, or it was placed in a form-encoded context where + is converted to a space. Encode exactly once, at the moment you build the parameter.
Should I encode the whole URL?
No. Encode each parameter value separately - encoding the whole thing escapes the :// and the & that hold the URL together, producing a single meaningless parameter. Path segments follow slightly different rules than query values, so treat the two separately.