URL Anatomy is built on a client-side privacy model: all parsing, decoding, and analysis run entirely in your browser. No URL, cURL, JSON, JWT, or pasted payload is sent to our servers or any third party. This design choice has direct implications for security and compliance.

Traditional server-side decoders (e.g. many "JWT debugger" or "URL parser" tools) send the input to a backend, where it may be logged, stored, or processed for analytics. That creates exposure: sensitive tokens, API keys in query params, or PII can leak. By contrast, a client-side implementation keeps the data on the device. The only network requests are for static assets (HTML, JS, CSS) and optional ads; the actual user content never leaves the user agent.

For developers handling production JWTs, staging URLs with credentials, or links containing tracking parameters, this means you can safely paste and inspect without trusting a remote service. The tool works offline after the initial load, reinforcing that no live server dependency is required for core functionality.

The input accepts three types of content. URLs are parsed into protocol, host, path, and query; each parameter is decoded and analyzed (JWT, timestamps, UUIDs, tracking params, etc.). cURL commands are recognized automatically: we extract the URL, HTTP method, headers (e.g. Authorization decoded when possible), and request body. Raw JSON (e.g. a request body) opens the same structured view as a cURL payload: formatted JSON, detected fields, and per-field edit/copy/generate.

All processing stays in your browser. Use one input for URLs, API snippets, or JSON payloads—no switching tools.

Structure overview

A URL is parsed into well-defined components. The scheme (e.g. https:) defines the protocol. The host (authority) includes the domain and optional port (e.g. :443). Omitting the port uses the default for the scheme (443 for HTTPS, 80 for HTTP).

The path is the hierarchical part after the host, e.g. /api/v1/users. Path segments are often used for routing and resource IDs. The query string (after ?) holds key-value pairs (e.g. ?utm_source=google). Values must be percent-encoded when they contain reserved characters. The fragment (after #) is client-only and is not sent to the server in HTTP requests; it is commonly used for in-page anchors or client-side routing.

Understanding this anatomy is essential for debugging redirects, building correct query params, and avoiding security issues (e.g. open redirects or sensitive data in query strings). This tool surfaces each component so you can verify encoding, detect tracking parameters, and validate structure.

Three parts

A JSON Web Token is composed of three Base64url-encoded segments separated by dots: Header.Payload.Signature. The header typically contains alg (e.g. HS256, RS256) and typ (JWT). The payload holds claims (e.g. sub, exp, custom data). The signature is computed over Header.Payload using the algorithm and secret or public key.

Decoding the payload (Base64url decode then JSON parse) is not a security operation: anyone can do it. JWTs are designed to be readable; integrity and authenticity are guaranteed by the signature. Verifying the signature requires the secret (symmetric) or the correct public key (asymmetric). Without that key, you cannot confirm that the token was issued by a trusted party or that it was not tampered with. Therefore: decoding here is safe and useful for inspection and debugging; it does not imply that the token is valid. Always verify signatures in your backend before trusting any claim.

Be cautious with tokens in URLs (e.g. in query params or fragments). They can be logged in server access logs, stored in browser history, or leaked via Referer. Prefer sending JWTs in headers (e.g. Authorization: Bearer <token>) in production.

Risks in URLs

XSS (Cross-Site Scripting): If a URL or its components (e.g. query params, fragment) are reflected into the page without proper encoding, an attacker can inject scripts. For example, ?q=<script>...</script> can execute if the value is written into the DOM as HTML. Defenses include strict output encoding (e.g. textContent, or safe HTML sanitization) and Content-Security-Policy.

Open redirects: A parameter like redirect= or url= that is used to send users to another URL can be abused if the target is not validated. Attackers can use your domain in phishing links (e.g. yoursite.com?redirect=https://evil.com). Always whitelist allowed redirect hosts or paths and reject any external or absolute URLs unless explicitly allowed.

Sensitive data in query params: Passwords, API keys, or tokens in query strings are dangerous: they appear in server logs, browser history, and Referer headers. Prefer POST bodies or secure headers for secrets, and never log or expose full URLs that contain credentials. This tool helps you spot such parameters so you can remove or refactor them.

Tracking parameters

UTM parameters (utm_source, utm_medium, utm_campaign, etc.) are used for campaign attribution. They tell analytics tools where traffic came from. They are not inherently malicious but add noise and can be used for tracking. fbclid (Facebook) and gclid (Google Ads) are click identifiers that enable ad platforms to attribute conversions; they also extend the URL and can be used for cross-site tracking.

Removing these parameters when sharing or bookmarking links reduces tracking surface, shortens the URL, and avoids leaking referral context to third parties. Many users prefer "clean" links for documentation, support tickets, or internal sharing. This tool detects common marketing and tracking params and can output a stripped URL for copying. Note: stripping tracking params may break some analytics or attribution flows if you rely on them; use consciously depending on your use case.

From a privacy perspective, minimizing the number of identifiers (including in URLs) aligns with principles of data minimization and gives users more control over what is shared when they forward or save a link.