URL Validator

Validate URLs and inspect their components: protocol, host, path, query parameters, and hash.

URLs (one per line)

URL	Status	Protocol	Host	Path	Query	Fragment
https://example.com/path?foo=bar&baz=qux#section	Valid	https:	example.com	/path	?foo=bar&baz=qux	#section
https://api.example.com:8080/v1/users?page=2	Valid	https:	api.example.com:8080	/v1/users	?page=2	—
not-a-valid-url	Invalid	—	—	—	—	—
ftp://files.example.com/file.txt	Valid	ftp:	files.example.com	/file.txt	—	—
https://user:[email protected]/secure	Valid	https:	example.com	/secure	—	—

URL Validator and Parser

This tool uses the browser's native URL API to parse and validate URLs. It checks whether a URL conforms to RFC 3986 and breaks it into its components: protocol (scheme), host (hostname + port), pathname, search (query string), and hash (fragment). Paste multiple URLs — one per line — to bulk-validate a list. All processing runs entirely in your browser; URLs are never sent to a server.

Built and maintained by Meet Shah · Last updated 24 July 2026

What this tool is used for

Checking why a URL your code built is rejected by a client library.
Inspecting the parsed components of a long URL to see where a query parameter actually landed.
Confirming that a redirect target is absolute and has the scheme you expect.
Validating a list of links before importing them.
Working out whether a fragment or a query is swallowing part of a value.

Frequently Asked Questions

What does valid actually mean here?: Parseable by the WHATWG URL standard — the same parser your browser uses for every link. It says nothing about whether the host exists, resolves, or answers. https://example.invalid parses perfectly and will never load, and that distinction is the whole point of the check.
Why does a URL with no dot in the host pass?: Because a hostname needs no dot to be well-formed. https://localhost is valid, and so is https://intranet — an internal machine name is a perfectly legal host. If you need a public domain specifically, check for a registrable suffix separately; URL syntax alone will never enforce it.
Are non-web schemes accepted?: Yes. ftp:, mailto:, file: and custom application schemes all parse, because the standard defines a URL far more broadly than a web address. Only URLs whose scheme is a special one — http, https, ws, wss, ftp, file — get full host parsing; the rest keep everything after the colon as an opaque path.
Why is a relative path invalid?: Because /about has no scheme and no host, so there is nothing to resolve it against — the parser needs a base URL to make sense of it, and none is supplied here. Prefix it with an origin to check it, and remember a relative link is not invalid in a page, only out of context.
Does it warn about credentials in the URL?: No, it simply parses them: https://user:[email protected] is a valid URL and reported as such. Browsers have been steadily restricting that form because of phishing, and it should never appear in a link you ship — treat any URL with an @ before the host as a finding, whatever a validator says.

Common errors and gotchas

Assuming valid means reachable. Parsing says nothing about DNS, TLS or whether anything answers.
Omitting the scheme, after which many parsers treat the host as a path.
Leaving an unencoded space or ampersand, which either fails or silently splits a parameter.
Treating a trailing slash as insignificant. For a path it can be a different resource entirely.
Reading the fragment as something the server sees. It never leaves the client.