URL parser

URL parser is a free tool that separates a URL into its scheme, path, and query components using PHP's parse_url function.

How can URL parsing isolate an API routing problem?

URL parsing lets you compare the address your application produced with the components your router, proxy, or API handler will read. Paste the exact URL from a request log, redirect header, webhook configuration, or third-party response, then inspect the returned Scheme, Path, and Query values.

This is useful when a URL looks correct as a whole but your application sends a request to the wrong route or supplies unexpected parameters. For example, an unencoded question mark intended as path data ends the path and begins the query. Percent-encoding can also hide delimiters that would otherwise divide components.

• Compare the Path with the route registered by an application such as /v2/orders/482.
• Check whether the Query contains the parameters expected by an API endpoint.
• Confirm that the Scheme is https when diagnosing redirects or mixed-scheme callback URLs.
• Parse third-party URLs before copying their components into deployment configuration.

The parser analyzes the supplied address. It does not contact the destination, test an API, follow redirects, or confirm that a route exists.

Reading the three returned components

The Scheme identifies the URI scheme without the following colon. Common values include http, https, and ftp. A relative reference such as /account/settings has no scheme.

The Path is the hierarchical portion used for routing or resource identification. In an HTTP URL, it commonly starts with a slash. Percent-encoded data remains encoded, so %20 does not automatically become a space.

The Query is everything after the first query delimiter and before any fragment delimiter. The returned value does not include the leading question mark. It remains a single query component rather than a decoded map of parameter names and values.

The tool reports only Scheme, Path, and Query. It does not return separate fields for the host, port, username, password, or fragment. If your debugging task depends on one of those components, the tool's Scheme, Path, and Query fields are not sufficient.

Example input

https://api.example.com/v2/orders/482?expand=items&locale=en-US

Returned components

Scheme = https

Path = /v2/orders/482

Query = expand=items&locale=en-US

Another example input

ftp://files.example.org/releases/app.zip?mirror=us

Returned components

Scheme = ftp

Path = /releases/app.zip

Query = mirror=us

What input patterns can produce misleading results?

Missing delimiters, incorrect encoding, and incomplete absolute URLs commonly produce components that differ from what the author intended. PHP's parse_url function is a component parser, not a standards-compliance validator, so successful parsing does not prove that a URL is valid or usable.

• Missing scheme delimiter. Text such as example.com/report can be treated as a path rather than as an HTTP host and path.
• Encoded question mark. In /search%3Fq=books, %3F is path data. It does not start a query.
• HTML escaping. A URL copied from source markup may contain &. Parsing does not turn that entity into an ampersand.
• Spaces. A literal space may remain part of the parsed component even though a URL producer would commonly encode it as %20.
• Unicode characters. Accented or non-Latin characters are not automatically normalized, percent-encoded, or converted to an internationalized domain representation.
• Malformed authority or port syntax. Seriously malformed input can cause parse_url to fail instead of returning useful components.

Numbers have no special meaning unless their position gives them one. Digits in a path remain path data, while digits following a valid port separator belong to the authority portion, which this tool does not display. Empty input has no meaningful URL components to extract.

When is splitting a URL unnecessary?

Parsing is unnecessary when the complete URL already works and no component-level inspection is needed. It also adds little value when an application only passes an opaque URL from one trusted system to another without reading or changing it.

Do not parse a URL merely to make it shorter, encode parameters, verify ownership, or determine whether a destination is safe. Likewise, parsing is not a substitute for application-specific validation before deployment.

For automated processing, a language-native URL API or a command-line script is usually easier to place in a repeatable test. The online tool supports one-off manual URL component inspection of a value from a log, configuration file, or third-party payload.

Common questions about URL parsing

Does parsing decode percent-encoded query values?

No. parse_url separates the query component but does not apply percent-decoding to individual names or values. Decode parameters only after splitting them according to the query format your application expects, since decoding too early can turn encoded delimiters into structural characters.

Why is the part after a number sign missing?

The portion after # is the fragment, and Fragment is not one of this tool's returned fields. Web browsers commonly use fragments for client-side navigation, and they do not normally send them in an HTTP request to the server.

Will the parser tell me whether a URL is malicious?

No. Component extraction does not assess reputation, inspect downloaded content, resolve DNS, or detect phishing. Treat unfamiliar URLs cautiously even when their Scheme, Path, and Query parse cleanly.

Does the tool send the URL to a server?

Yes. The input travels to the server over HTTPS, where PHP's parse_url function performs the work, and the input is not stored. Avoid submitting secrets contained in URLs or query strings when component inspection can be done with a redacted copy.

Can it parse schemes other than HTTP and HTTPS?

parse_url can recognize other syntactically suitable schemes, such as ftp, but the meaning of the remaining components depends on that scheme. A mailto URI does not use a // authority component and does not necessarily divide into components the same way as a web URL.

Final checks

Before using a parsed value in code or configuration, verify the original delimiters, preserve required percent-encoding, and validate the result under the rules of the receiving application. If the issue concerns request headers rather than the URL itself, a User agent parser may be the more relevant next check.