Construct a URL from parts. Each field is encoded correctly for its context — paths preserve /, query values get fully encoded, fragment gets its own treatment.
A URL is assembled from ordered pieces — protocol, host, port, path, query, and fragment — and each has its own encoding and its own delimiter. The builder above fills each field into the right slot and encodes it for that context, so you don’t hand-concatenate strings and introduce the subtle bugs that break links and analytics. Two of those bugs are worth understanding, because they’re the ones that quietly corrupt tracking parameters.
The query string has a strict structure defined by RFC 3986: a single ? marks where the path ends and the parameters begin, and every pair after that is joined with &. Two rules follow:
? in the whole URL. The first question mark is the switch from path to query; any further ones are treated as literal data within the query, not as new separators.&, not another ?. Adding parameters to example.com/shop?product_id=45 means continuing with &utm_source=... — starting a second ? would fold your new keys into the existing value and drop them. When you enter parameters as key/value pairs, the builder handles this switch for you.A frequent, costly mistake is placing parameters after the fragment: example.com/page#section?utm_source=google. The browser treats everything after the # as a client-side fragment identifier and never sends it to the server — so those tracking parameters are silently dropped before the request leaves the browser, and your analytics never see them.
The correct order is always query first, fragment last: example.com/page?utm_source=google#section. The builder enforces this by giving the fragment its own field and placing it at the end of the assembled URL, so parameters can’t end up stranded behind the #.
Hand-joining a URL is where duplicate ?s, missing &s, unescaped values, and double-encoding creep in — and a single malformed parameter can split a page into duplicate indexed URLs or break attribution entirely. Constructing each part through one tool keeps the delimiters correct and encodes each value exactly once. This applies to any parameters, tracking or otherwise: to add UTM tags (utm_source, utm_medium, utm_campaign), enter them as ordinary key/value pairs and the builder encodes each value for you — it’s a general-purpose builder, so any parameter names work.
See also: How to pass a URL as a query parameter — a step-by-step guide with runnable code.
? boundary (§3.4), the fragment after # (§3.5), and percent-encoding of values (§2.1). rfc-editor.org/rfc/rfc3986 §3.4key=value&key=value serialization used in query strings, which URLSearchParams follows. url.spec.whatwg.orgHonest scope: RFC 3986 defines the single ? boundary and the fragment’s position; the key=value& pair structure inside the query is the WHATWG form-urlencoded convention. This is a general-purpose URL builder — UTM tracking parameters are simply one kind of key/value pair, not a built-in feature.
It constructs a URL from its parts — scheme, host, path, query parameters, and fragment — encoding each field correctly for its context. Paths keep their slashes, query values are fully encoded, and the fragment gets its own treatment, so the result is always well-formed.
As you fill in each field, the builder applies the right encoding for that position: a space in a query value becomes %20, reserved characters in values are escaped, and structural characters stay literal where they belong. You enter readable text and get a correctly encoded URL.
Yes — add them as ordinary query parameters (for example utm_source, utm_medium, utm_campaign as key/value pairs) and the builder encodes each value correctly. It’s a general-purpose builder rather than a UTM-specific form, so any parameter names work.
Hand-joining strings is where missing delimiters, unescaped &, and double-encoding bugs creep in — and a broken parameter can quietly ruin tracking. Building each part through one tool keeps the delimiters and encoding correct.
If a value contains &, =, or a space, leaving it raw would collide with the structural characters that separate parameters, breaking the query. Encoding each value keeps it intact as data.
You can set a custom scheme (like myapp://) as the protocol and build the rest of the path and parameters around it, which is the basis of a mobile deep link. The builder treats the scheme as a field like any other.
Because you manage parameters as discrete key/value entries rather than appending to a raw string, it’s easy to see and update an existing key instead of accidentally adding it twice.
Put the full URL in as a query value — the builder encodes its ://, ?, and & so the nested URL travels safely as a single value. That’s the correct way to pass a return or redirect URL.
Yes — it constructs the URL locally with JavaScript, so nothing you enter is uploaded and it works offline.
Written and maintained by the urlencodedecode.com team. Every technical claim on this page is verified against primary sources — the RFCs (3986, 3629, 4648, 7578), the WHATWG URL Standard, and official vendor or language documentation — rather than second-hand summaries. When a source contradicts a common assumption, we follow the source and note the discrepancy. Corrections: contactus@urlencodedecode.com.