Encoded URLs are unreadable by design. A tracking link that arrived in an email, a redirect chain from an ad platform, or a parameter logged by your analytics can easily run to several hundred characters of %3A%2F%2F with the meaningful part buried in the middle.
Decoding turns that back into something you can read - and, more usefully here, into a table showing exactly which parameters are being passed and what each one contains.
The parameter table
This is what separates a useful decoder from a plain one. After decoding, any query string is split into name and value pairs and laid out as a table. Instead of scanning a long line for where one parameter ends and the next begins, you see them listed.
It is the fastest way to answer questions that come up constantly. Which UTM parameters is this campaign link actually carrying? Is the click ID being appended twice? What is inside the state parameter of that OAuth callback? Where does this redirect chain end up?
Double encoding
The repeat option decodes until nothing is left to decode, up to five passes.
Double encoding happens when a URL is encoded by two systems in sequence - an email platform wraps a link that a tag manager had already wrapped, for instance. The telltale sign is %25 appearing in the string, since %25 is the encoding of the % character itself. Where you expected %20 for a space you find %2520.
Leave the repeat option off if your data legitimately contains percent signs, because a single pass is the honest reading of the string. Turn it on when you are unwrapping a link that has been through several systems.
Plus signs
The plus-as-space option matters because the two encoding conventions disagree. In form-encoded data a plus means a space; in general percent-encoding it means a literal plus. Most query strings follow the form convention, so the option is on by default.
Turn it off when the value genuinely contains a plus - a phone number in international format, or an email address using plus addressing such as user+tag@example.com. With the option on, that address decodes to user tag@example.com, which is wrong and quietly so.
A caution
Decoding a link is safe. Visiting it is not necessarily. Shortened and encoded URLs from unsolicited email are frequently how phishing pages are reached, and reading the decoded destination is a sensible precaution before clicking. If the decoded address does not look like the organisation the message claims to be from, that is your answer. Nothing is transmitted from this page, so decoding a suspicious link here does not touch the site in question.