Check whether a string is a valid URL. If it isn’t, get a clear explanation of why.
A web address isn’t an unstructured string — it’s a strictly arranged set of components, each governed by its own syntax rules in RFC 3986. Validation means checking each part independently against those rules, separating the structural delimiters from the dynamic data so a malformed input is caught before it causes a routing bug, a failed request, or an injection risk downstream. The validator above parses your input the same way a browser’s native URL object does, then reports which component (if any) is malformed and why.
Each row below maps a URL component to its RFC 3986 syntax rule and the practical check a validator applies:
| Component | Syntax rule (RFC 3986) | Validation check | Example |
|---|---|---|---|
| Scheme | Letter, then letters/digits/+ - ., ending in : — case-insensitive (§3.1) |
Present, well-formed, and ideally on an allowed list (e.g. http, https) to exclude unsafe schemes |
https: |
| Authority | Host as a registered name, IPv4 address, or bracketed IPv6 literal (§3.2.2) | Host resolves to a valid form; IPv4 octets in range; IPv6 enclosed in [ ] |
example.com |
| Port | A colon followed by decimal digits (§3.2.3) | Numeric; in practice within the TCP range 0–65535 (a 16-bit value) | :8080 |
| Path | Hierarchical segments separated by / (§3.3) |
Special characters within segments are percent-encoded; structural slashes left intact | /api/v1/data |
| Query | Begins with ?; key/value pairs (§3.4) |
Pairs separated by &, keys and values joined by =, values encoded |
?id=102&sort=asc |
| Fragment | Begins with # (§3.5) |
Client-side only — never sent to the server; its bounds are confirmed but it doesn’t affect routing | #heading-summary |
Beyond syntax, robust validation also serves security: rejecting malformed or unexpected inputs is a first line of defense against open redirects and server-side request forgery, and it keeps broken strings out of your database. Validation is a check on structure, not a guarantee that a URL is safe to fetch — pair it with an allowlist of trusted destinations when the URL will be followed.
See also: How to validate a URL programmatically — a step-by-step guide with runnable code.
URL parsing follows. url.spec.whatwg.orgxn--) for validation. rfc-editor.org/rfc/rfc3987Honest scope: RFC 3986 defines URI syntax. Whether a syntactically valid URL is reachable, safe to fetch, or points to a live host is a separate question — validation confirms structure, not trustworthiness. Browsers follow the WHATWG URL Standard, which differs from RFC 3986 in a few parsing details.
It checks whether a string is a well-formed URL and, if not, explains why. The check is based on URL syntax rules (RFC 3986 and the WHATWG URL Standard), so you can catch malformed links before they cause errors downstream.
Use URL.canParse(string), or wrap new URL(string) in a try/catch — if construction throws, the URL is invalid. This tool uses the same native parsing, so its verdict matches what your code would do.
URLs allow IPv6 hosts, embedded credentials, unusual ports, internationalized domains, and more, so a single regular expression almost always rejects valid URLs or accepts broken ones. Parsing with the URL standard is far more reliable than a regex.
An absolute URL includes a scheme (https://) and enough to locate the resource on its own. A validator flags a string that’s missing the scheme, since that makes it relative rather than absolute.
urllib.parse.urlparse() breaks a URL into components; checking that both scheme and netloc are present is a common way to confirm it’s a usable absolute URL before making a request.
The top-level domain is the final label of a host (.com, .org). Strict validators may check it against the IANA registry to confirm it’s a real extension, though syntactic validation alone doesn’t require that.
An IDN contains non-ASCII characters (like example.рф). It’s converted to Punycode — an ASCII form prefixed with xn-- — for validation and DNS resolution, since the domain system itself is ASCII-only.
Validators aimed at production often require a public domain and reject localhost or private addresses by default. Whether that’s desirable depends on your use case — for local development those addresses are perfectly valid.
It confirms the address is well-formed: IPv4 octets within range, and IPv6 addresses enclosed in square brackets (http://[::1]/) as the URL syntax requires.
java.net.URL throws it when the string uses an unknown protocol or is structurally invalid — for example a missing or unrecognized scheme. It’s the JVM’s equivalent of failing this kind of validation.
Validating catches malformed strings early and reduces the risk of storing something that later breaks a page or, if rendered unsafely, enables XSS. Clean input keeps stored data reliable.
If your app redirects to a user-supplied URL, validating it against an allowlist of trusted destinations stops attackers from bouncing users to phishing sites. Validation alone isn’t the whole fix, but it’s a key part.
Server-Side Request Forgery abuses a server into calling internal addresses. Checking a URL against rules that block internal ranges (like 127.0.0.1 or private IPs) before the server fetches it is a standard defense.
A raw space isn’t legal in a URL, so a validator flags it as a syntax error. Encoded as %20 (or + in a query) it’s valid. The tool points out exactly where the problem is.
Platforms run scrapers to build link previews; a malformed or unvalidated URL can make the preview fail to render. Validating your links first helps them display correctly when shared.
Feed it edge cases — custom ports, IPv6 hosts, internationalized domains, very long query strings — and confirm it accepts the valid ones and flags the broken ones. A good validator handles the awkward cases, not just simple links.
Yes — the URL you check is parsed locally in your browser and never uploaded, so it’s safe for private links and works offline.
Written and maintained by the urlencodedecode.com team. Every technical claim on this page is verified against primary sources — the RFCs (3986, 3629, 4648, 7578), the WHATWG URL Standard, and official vendor or language documentation — rather than second-hand summaries. When a source contradicts a common assumption, we follow the source and note the discrepancy. Corrections: contactus@urlencodedecode.com.