Skip to content
D1
EN

URL utility

URL Splitter

Split any URL into scheme, host, path, query parameters, fragment and normalized form.

This form calls the relative endpoint: /site-api/tools/url-splitter

How to use this tool

  1. Paste a complete absolute URL into the input field. The string must include a scheme (http or https) and a host name, for example https://api.example.com/v1/users?page=2&utm_source=newsletter#settings. Relative paths such as /docs/guide or bare hostnames without a scheme are rejected because the parser needs an unambiguous starting point.
  2. Submit the form or press Enter. DN01 parses the URL entirely in your browser and on the server without opening a network connection to the destination host. No HTTP request is sent to the site you are analyzing, which makes the tool safe for inspecting production callbacks, signed redirect URIs, and internal staging URLs.
  3. Review the structured breakdown: scheme, host, hostname, port, path, path segments, raw query string, individual query parameters, fragment, origin, and a normalized URL. Each field is labeled so you can copy values into OAuth consoles, CDN rule builders, analytics filters, or webhook logs without manual string splitting.
  4. Use the normalized URL and origin when you need a canonical form for comparisons. Compare hostname versus host when debugging port-specific rules, and remember that the fragment (#...) is parsed locally but is never transmitted to the server on a normal page navigation—an important distinction when tracing SPA routing or OAuth implicit flows.

What the result shows

The result is split into the signals that matter for this specific check.

FieldPurposeExample
SchemeIdentifies the protocol layer (http or https). CDN caches, HSTS policies, and OAuth providers often treat http and https as different redirect targets even when the host matches.https
HostThe authority segment including hostname and explicit port when present. Useful when a rule must match exactly what appears before the path.cdn.example.com:8443
HostnameHost without the port suffix. Load balancers, cookie domain rules, and TLS certificate names usually key off hostname alone.cdn.example.com
PortExplicit or implied service port. Empty for default 80/443; non-empty when the URL specifies :8080 or similar. Critical for webhook listeners and dev tunnels.8080
PathPercent-encoded path from the first slash through the query delimiter. Reflects how servers route requests before query parsing./api/v2/webhooks/stripe
Path segmentsOrdered list of non-empty path components after splitting on /. Easier to read than a single path string when building CDN path patterns or REST resource maps.["api", "v2", "webhooks", "stripe"]
Query stringRaw key=value pairs after ? without decoding semantics beyond parsing. Handy when diffing two URLs character by character.utm_source=email&utm_campaign=q1&page=3
Query parametersStructured list of keys and values, including duplicates when repeated keys appear. Essential for UTM audits, OAuth state/nonce checks, and pagination args.utm_source=email, page=3
FragmentClient-side anchor after #. Browsers do not send this to the server on navigation; SPAs may still read it in JavaScript for routing.section-pricing
OriginScheme plus host (with port if non-default). Matches the browser Same-Origin Policy comparison base for CORS and postMessage targets.https://cdn.example.com:8443

When this check helps

OAuth and OpenID Connect integrations fail in subtle ways when redirect_uri values differ by a trailing slash, wrong port, or http versus https. Providers compare the registered callback literally against the value your app sends in the authorization request. Before you paste a URI into Google, Microsoft, or Okta, split it with DN01 and confirm scheme, hostname, path, and query match the allowlist entry character for character. If your app builds callbacks dynamically, paste the live value from a failed login attempt and compare origin and normalized URL against what you registered. A mismatch on hostname casing is usually harmless because DN01 lowercases host parts, but a mismatch on path segments or an unexpected query parameter will break the flow. This check costs nothing and avoids round-trips through provider error pages.

Marketing teams tag links with UTM parameters to attribute traffic in analytics. Over time, campaigns accumulate inconsistent spellings (utm_source versus utm_Source), duplicate keys, or encoded characters that look identical in a spreadsheet. Paste each landing URL into the splitter and read the structured query parameter table instead of counting ampersands manually. You can verify that utm_medium, utm_campaign, and utm_content are present before publishing an email blast, and catch accidental double question marks when one URL was concatenated onto another. Because parsing is local, you can safely inspect unreleased campaign links that contain embargoed slugs.

CDN and reverse-proxy operators write cache keys and origin rules from URL components. A rule that matches /images/* must not accidentally include query strings that bust cache, and hostname-based routing must distinguish www from apex. Splitting a problematic request URL shows whether the path segments align with your edge rule order and whether the port in host affects rule matching on dev environments. When migrating from path-prefix routing to segment-based routing, comparing segment lists across old and new URL patterns clarifies which directories need redirect maps.

Webhook debugging often starts with a log line containing a full callback URL. Payment processors, GitHub, and CI systems echo the exact URL they attempted to reach. Paste that URL to separate the path that your router must register from query parameters that signature verification might include or ignore. If the listener binds to a non-default port, the port field confirms whether the sender used :443 explicitly or relied on defaults. This is faster than squinting at colon positions inside a long HTTPS string.

Single-page applications frequently move state into the fragment (#/dashboard?tab=billing) where server logs never see it. When supporting users who report “wrong page after login,” split the URL they copied from the address bar and inspect the fragment separately from path and query. Support engineers can explain whether the issue is server routing (path/query) or client router configuration (fragment). DN01 documents that fragments are parsed for analysis but would not appear in a classic server access log line.

Security reviews sometimes receive suspicious links using disallowed schemes. DN01 accepts absolute http and https URLs and rejects javascript:, data:, and file: inputs at parse time, aligning with safe inspection practices. Analysts can document scheme and host for ticketing without executing code or fetching arbitrary resources. For https links, hostname extraction supports WHOIS or DNS follow-up in separate tools while keeping this step purely structural.

API gateways and microservice meshes append path prefixes when exposing internal services. A gateway might expose https://public.example.com/payments/v1/charges while the backend sees /v1/charges. Splitting both the external and internal representations as segments makes prefix drift visible early in integration testing, before you deploy route tables to production.

What to review when results look wrong

If parsing fails with “absolute URL with scheme and host is required,” add https:// (or http://) before the host and ensure there is no leading whitespace. Hostnames alone such as example.com/path are not valid absolute URLs for this tool because the scheme is missing. Copy the value directly from the browser address bar when possible.

javascript:, data:, and file: schemes are blocked intentionally. These are not web navigations suitable for redirect or CDN analysis. Rewrite the input as an https URL if you are studying a page that was originally opened through another scheme, or strip executable payloads before parsing.

When query parameters look empty but you expected values after ?, check for encoding issues. A malformed percent sequence in the full URL can prevent parsing. Paste the URL encoded as it appeared in the source system (log file, email HTML, JSON field) rather than a partially decoded variant.

If host and hostname differ only by port, your routing rule may need to mention the port explicitly. Default https omits :443; development URLs with :3000 will show a non-empty port field. Do not assume the normalized URL rewrites custom ports away—it preserves what you entered.

Duplicate query keys are preserved as separate rows in the parameter list. Some frameworks keep only the last value; others concatenate. The splitter shows what is structurally present, not what your framework will choose at runtime.

How to interpret the result

The scheme establishes transport expectations. Modern OAuth providers require https redirect URIs in production, while local development may temporarily allow http on localhost. Seeing scheme separately from origin helps you reason about mixed-content upgrades and HSTS preload requirements without re-reading RFC text. When a URL uses a non-http scheme that still parses in other tools, DN01 may warn that no network access occurred—treat that as a reminder that only http/https are first-class here.

Host versus hostname separation mirrors how URLs are specified in RFC 3986 and how many server APIs expose peer names. TLS Server Name Indication uses hostname; listening sockets bind to ports. A CDN health check might target hostname on 443 while an internal docker service publishes host:8080 on a bridge network. Mapping both fields reduces confusion when engineers use “host” informally to mean only the DNS name.

Path and segments together support both string-oriented and REST-oriented thinking. Reverse proxies often document rules as prefix strings; application code often splits segments for authorization checks. Percent-encoding in the path field reflects wire form—spaces as %20, unicode as UTF-8 bytes—so comparisons to access logs remain faithful. Segment lists omit empty components from leading or trailing slashes, which matches intuitive “folder” boundaries.

Query handling exposes both raw and parsed views because analytics and signature algorithms care about different representations. Marketing cares about decoded utm_campaign names; HMAC webhook verification may require the raw query substring exactly as sent. Listing duplicate keys makes it obvious when a client appended ?filter=a&filter=b. Empty values appear as keys with empty strings, which is valid and distinct from a missing key.

Fragments are the most misunderstood URL part. On a traditional full page load, the browser requests only the portion before #; the fragment is interpreted locally after the response arrives. That is why fragment changes do not trigger new server access log lines. OAuth 2.0 implicit flows historically returned tokens in fragments, so security reviews must examine fragments even when operators never see them in nginx logs. DN01 surfaces fragments for education and SPA debugging, not because they affect server-side routing.

Origin and normalized URL support equivalence checks. Origin is the security boundary for CORS preflight and Web Storage partitioning in modern browsers. Normalized URL lowercases scheme and host per tool rules, helping compare two inputs that differ only by case or trivial encoding. Use normalized output when generating allowlists, but always confirm whether your identity provider expects case-sensitive paths before relying solely on normalization.

Recommended workflow

  1. Capture the exact URL from logs, browser, or provider dashboard without manual edits.
  2. Paste into DN01 URL Splitter and confirm parse success and scheme http/https.
  3. Record scheme, hostname, path segments, and query parameters relevant to your ticket.
  4. Compare origin or normalized URL against registered OAuth, CDN, or webhook expectations.
  5. Document mismatches (port, trailing slash, extra query key) and retest after configuration changes.

Tool vs manual checks

Manual splitting with text editors works for one-off URLs but scales poorly when query strings span dozens of parameters. A single misplaced ampersand or an = inside a base64 value breaks naive split-on-& scripts. DN01 uses a proper URL parser aligned with Go’s net/url semantics on the backend and equivalent browser-side validation, reducing edge-case surprises.

Browser DevTools Network panel shows requested URLs but only after a request occurs. For preflight validation of redirect URIs or embargoed campaign links, issuing a request may be undesirable or impossible. Local parsing gives structure without network side effects.

Programming language one-liners (python -c, node -e) are flexible but not shareable across a marketing or support team. DN01 presents a consistent table with labels in your language, exportable result pages, and no local runtime installation.

Spreadsheet formulas can extract MID between delimiters yet struggle with encoded query strings and duplicate keys. They also hide the fragment entirely if you forgot it was part of the copied cell. The splitter keeps fragments visible in their own row.

Online URL parsers vary in which components they expose and whether they fetch the remote page. DN01 is tool-specific to absolute http/https structural parsing with explicit rejection of dangerous schemes and no outbound fetch.

curl -I or wget probes confirm reachability but conflate DNS, TLS, and HTTP status with pure URL structure. Use those tools after DN01 confirms the path and query are what you intend to hit.

Reading RFC 3986 is invaluable for standards depth but slow during incident response. DN01 operationalizes the common fields incident responders need in a tabular view.

Why use DN01

  • Parses absolute http/https URLs locally—no request to the destination site.
  • Exposes scheme, host, path segments, query keys, fragment, and origin in one view.
  • Rejects javascript:, data:, and file: schemes for safer inspection workflows.
  • Built for OAuth redirect URIs, UTM reviews, CDN rules, and webhook log analysis.

FAQ

URL splitter FAQ

Scheme, host, path segments, query parameters, fragments, and safe handling of credentials in URLs.

What parts of a URL does the splitter show?

It breaks input into scheme, username, password-present flag, hostname, port, path with segments, query string with decoded key/value pairs, fragment, origin, and a normalized URL when parsing succeeds.

Is it safe to paste URLs that contain passwords?

DN01 flags when userinfo contains a password but does not echo the secret in shareable fields. Avoid pasting production credentials; treat any URL with embedded passwords as sensitive and rotate them if exposed.

What is the difference between host and hostname?

Hostname is the domain or IP without port. Host includes the port when present, such as example.com:8443. Both help when debugging redirects, CDN origins, and API base URLs.

Why might a URL look valid but fail parsing?

Missing scheme or host, javascript:/data:/file: schemes, malformed percent-encoding, or illegal characters trigger errors. Add https:// for bare domains or fix encoding before re-running.

How are query strings and fragments handled?

Query parameters are split on & and decoded into a list. Fragments (#section) stay client-side in browsers and are shown separately because servers typically never receive them.

Can I automate URL parsing?

Yes for scripts and log pipelines. See the API docs after you request an API token for the structured JSON response.

Tool switcher

Pick the next step in your domain or security workflow.

Full tool catalog

Guides

Practical guides for common URL Splitter tasks — DNS records, troubleshooting steps, and links to our free tools.

Back to URL Splitter