URL Validator
The URL parses correctly
It is well formed. Whether the address responds is a separate question. That needs a request, which this page does not make.
- Scheme
- https
- Host
- example.com
- Port
- (default)
- Path
- /path
- Query
- ?q=1
- Fragment
- #top
The parser reads a URL with the browser's own URL implementation, the same one that decides what a link does, and shows you every part, what it normalises to, and anything worth a second look. It checks structure, not existence: whether the address responds needs a request, which this page does not make.
How it works
The WHATWG URL parser is what browsers, Node and fetch all use. Running your URL through it means the result is what will actually happen, rather than what a regular expression thinks should happen.
- A URL needs a scheme. example.com on its own is a hostname, and a parser will reject it, which is why relative links break when they are treated as absolute.
- Normalisation lowercases the scheme and host, removes a default port, and resolves dot segments in the path. The normalised form is shown whenever it differs from what you typed.
- A hostname with non-ASCII characters is converted to punycode before any request is made.
- Credentials embedded before the hostname are flagged: browsers increasingly refuse them, and they are a long-standing phishing pattern.
Two URLs that look the same can be different origins. A trailing dot on the hostname makes it a fully qualified name, which browsers treat as a separate origin for cookies and storage, an occasional and very confusing source of bugs.
Examples
A complete URL
URL
https://example.com/path?q=1#top
Result
Scheme https · host example.com · path /path · query ?q=1 · fragment #top
Every part separated out. The fragment never reaches the server. It is handled entirely by the browser.
No scheme
URL
example.com/path
Result
Rejected: no scheme
This is a hostname and a path, not a URL. Prefixing https:// makes it valid, which is exactly what a browser address bar does silently.
Embedded credentials
URL
https://user:[email protected]
Result
Parses, with a warning
Valid syntax and a classic phishing shape, because the part before the @ can be made to look like the real destination. Most browsers now strip or refuse it.
Frequently asked questions
Why is example.com rejected when it clearly works in my browser?
Because the address bar adds the scheme for you before parsing. Strictly, example.com is a hostname. A URL needs a scheme to say what protocol to use. Anything consuming URLs programmatically will reject it, which is why links stored without a scheme so often break.
Does a valid URL mean the page exists?
No. This checks that the address is well formed. Whether it resolves, responds or returns a 404 requires an actual request to that server, which this page does not make, and could not make reliably, since most sites block cross-origin requests from a browser.
What does the normalised form change?
The scheme and hostname are lowercased, a default port is dropped, :443 on https disappears, and dot segments in the path are resolved, so /a/./b/../c becomes /a/c. Two URLs that normalise identically point at the same resource even when the text differs.
Why does a trailing dot on the hostname matter?
Because example.com. is a fully qualified domain name and browsers treat it as a different origin from example.com. Cookies, storage and CORS all see two separate sites, which makes for a genuinely baffling bug when it appears.
Is a URL with spaces valid?
Not strictly, though the parser will encode them to %20 and carry on. A space in a link is a frequent cause of breakage because the surrounding markup or email client truncates at the space instead. Encode them before the URL reaches anything else.
What is punycode doing in my hostname?
It is how a domain with non-ASCII characters is represented in ASCII. München.de becomes xn--mnchen-3ya.de. DNS only handles ASCII, so the conversion happens before lookup. Browsers display the original characters, which is also why lookalike-character phishing is a concern.