URL encoding, repeated parameters and tracking fields

Structure and values need different handling

https://example.com/search?q=green+tea&tag=a&tag=b#results

The path is /search, q is a query key, and results is the fragment. The two tag entries are separate ordered pairs. Collapsing them into a plain object can lose one value. URL parser keeps both and never visits the destination.

In form-style query decoding, + becomes space. A literal plus should be %2B. In component mode, an unescaped + stays a plus.

Decode one layer at a time

%2520 decodes to %20 in one pass, not directly to a space. Decide whether a second layer belongs to your data before applying another pass. Invalid percent bytes should be corrected at the source, not silently replaced.

HTML entities are a different layer: & represents an ampersand in markup. Base64 is another representation altogether, mapping bytes to an ASCII alphabet. Base64URL changes two alphabet characters for URL contexts. None of these operations verify authenticity or provide encryption.

Keep campaign naming consistent

A UTM builder adds source, medium and campaign values through a URL-aware serializer. Agree on spelling and capitalization before sharing many links. The builder preserves unrelated parameters and fragments, and reports existing UTM fields that were replaced. It cannot guarantee that analytics software records a visit.

Clean only what you understand

URL cleaner removes only the selected known tracking names. It preserves unknown parameter pairs because they may select content. Deleting page=2 or q=green+tea changes the destination’s meaning.

A signed URL may depend on every original byte, so any change can invalidate it. Browser URL parsing can normalize host/path spelling even when query pairs are preserved. Check the destination yourself before sharing and do not treat a cleaned link as a safety verdict.