URL Parser & Query String Decoder
Break any URL into protocol, host, path, query, and hash — UTM-labeled, double-encoding flagged, JSON output.
Tool code processes selected files and entered content in your browser and does not submit them to a TOOLGRID processing endpoint. TOOLGRID measures tool usage, not the content you enter.
- No TOOLGRID input upload
- No account
- Review before copy
Loading tool…
What this tool does
Free URL parser that decomposes any URL into its scheme, host, path, query, and hash, decodes percent-encoded values, auto-labels UTM and tracking parameters, flags double-encoded strings, and emits a structured JSON view you can copy. Tool code runs in your browser and does not submit entered URLs to a TOOLGRID processing endpoint; no sign-up is required.
Break any URL into its parts: protocol, hostname, port, path, query parameters, and hash fragment. Each component is decoded and displayed separately for inspection, and the structured result is also available as a JSON object you can copy into a script or bug report.
Unlike basic parsers, every query parameter is annotated when it matches a known tracking convention — utm_source, utm_medium, gclid, fbclid, msclkid, ttclid, and so on — so you can see at a glance what the link is doing without memorizing every campaign-tag spec.
The parser also flags double-encoded values (where %2520 appears instead of %20). This is the most common URL bug in production — usually caused by encoding twice somewhere upstream — and most online parsers silently decode it once and hide the problem.
All parsing runs in your browser. Tool code does not submit entered URLs to a TOOLGRID processing endpoint; browser-local processing is not a blanket security guarantee for tokens, session IDs, or PII. Pair it with our query string builder or campaign URL workspace when you need to construct, not just inspect.
Where this tool earns its place
Marketing teams ship long URLs studded with UTM parameters, GCLID, FBCLID, and click IDs. Paste them to verify every parameter is set correctly before launching a campaign.
Mobile app URLs like myapp://path?param=value can be hard to read in flat text. Parse them to verify the route, payload, and any base64-encoded state inside.
After a chain of 301 or 302 redirects, compare the original URL to the final URL — confirm only intended parameters survived and tracking parameters were not silently stripped.
What to check before relying on the result
- Performance and maximum practical input size depend on browser memory, device speed, and the structure of the input.
- Review the generated result before replacing or publishing an original file.
Open a nearby browser tool when you need to validate, convert, or reuse the result.
How to use
01Use Cases
Marketing teams ship long URLs studded with UTM parameters, GCLID, FBCLID, and click IDs. Paste them to verify every parameter is set correctly before launching a campaign.
Mobile app URLs like myapp://path?param=value can be hard to read in flat text. Parse them to verify the route, payload, and any base64-encoded state inside.
After a chain of 301 or 302 redirects, compare the original URL to the final URL — confirm only intended parameters survived and tracking parameters were not silently stripped.
E-commerce and SaaS apps generate complex query-filtered URLs. Parse them to verify state encoding is consistent and decodable across views, devices, and shared sessions.
A visual breakdown makes URL parts concrete — show new engineers what 'query string', 'path', and 'hash fragment' actually mean in production URLs they will encounter on day one.
Tips & Tricks
- 01The hash fragment is never sent to the server
Everything after # stays in the browser. Use it for client-side state in single-page apps, not for tracking or analytics that need server-side capture.
- 02Multiple values per key use repeated parameters
Standard syntax is ?tag=a&tag=b&tag=c. Some PHP frameworks use ?tag[]=a&tag[]=b — non-standard but very common. URL Parser handles both.
- 03URLs over 2,048 characters can break in older browsers
While the URL standard allows much longer, Internet Explorer and some older clients cap at around 2K characters. Long URLs with many parameters may not survive everywhere — consider POST or a shorter encoding.
- 04Percent-encoding hides the raw bytes
%20 is a space, %2F is /, %3F is ?. URL Parser decodes these automatically, but the raw encoded form is shown too so you can spot double-encoded strings (which usually mean a bug).
- 05Internationalized domains use Punycode
Domain names with non-ASCII characters (for example café.com) are stored under the hood as Punycode (xn--caf-dma.com). Both forms are recognized and shown.
FAQ
02Does it support relative URLs?
It expects absolute URLs with a protocol for best results. For relative URLs like /path?param, prepend a base such as https://example.com to make parsing meaningful.
Does it decode percent-encoded values?
Yes. Query parameter values are shown in their decoded form alongside the raw encoded form, so you can verify the original input and spot double-encoded strings.
What if the URL includes a hash fragment?
The hash fragment is extracted and displayed as a separate parsed field, alongside the path and query string. Note that hash fragments are never sent to the server.
Is my URL data sent to your server?
URL Parser runs in your browser. Tool code does not submit entered URLs, tokens, session IDs, or parameters to a TOOLGRID processing endpoint. Review browser extensions and device security before handling sensitive values.
Can the parser handle URLs with international characters?
Yes. Both UTF-8 paths and Punycode (xn--) hostnames are parsed correctly. The decoded human-readable form is shown alongside the raw encoded form.
What is the difference between a path parameter and a query parameter?
Path parameters are named segments inside the URL path (for example /user/:id/posts/:postId resolving to /user/123/posts/45) — they're a convention of your routing framework, not a part of the URL standard. Query parameters come after the question mark (?sort=date). URL Parser surfaces the full path string and the query parameters; named path segments are application-defined, so we don't try to guess your routes.
How does the parser detect double-encoded URLs?
When a percent-encoded sequence appears inside an already-decoded value (for example %2520 instead of %20, or %253F instead of %3F), the parser raises a warning. Double-encoding usually means a URL was encoded twice somewhere upstream — a real production bug. Most other online parsers decode once and hide the problem; we flag it explicitly so you can trace the source.
Which tracking parameters does the parser label automatically?
All five UTM parameters (utm_source, utm_medium, utm_campaign, utm_term, utm_content) plus Google's gclid and gclsrc, Facebook's fbclid, Microsoft's msclkid, TikTok's ttclid, and a few platform-specific IDs. Each labeled parameter shows a short tag next to the value so you can scan a long URL and spot which platform owns each piece.
What does the JSON output include?
A structured object with href, protocol, host, hostname, port, pathname, search, hash, origin, a params array (each entry has key, value, decoded label, and a tracking flag), and a warnings array for issues like double-encoding. Copy it directly into a bug report, a script, or a test fixture.
How do I get just the domain without the protocol or path?
After parsing, copy the hostname field directly. To include the port, copy the host field instead. The protocol is always shown separately so you can recombine as needed.
Why does my URL fail to parse?
Most parse failures come from a missing protocol (no http:// or https://) or invalid characters in the hostname. The parser tries to auto-prepend https:// when no scheme is present; if it still fails, the hostname likely contains spaces or characters not allowed by the URL standard.