RFC 3986 or WHATWG — which?

WHATWG is the modern spec — what browsers actually implement. RFC 3986 is the formal definition that's slightly stricter. The tool defaults to WHATWG (accepts what a browser would accept) and you can toggle to strict RFC mode for sanity-check work.

Does a bare hostname pass validation?

By default no — URLs need a protocol (https://). Toggle 'allow protocol-relative' if you want //example.com/path to pass. Many use cases (CDN URLs, page redirects) work with protocol-relative.

What about IDN / Unicode domains?

Yes — café.example is normalised to its Punycode form (xn--caf-dma.example) and validated. Both forms pass; the tool shows the canonical Punycode for storage.

rfc 3986 · whatwg · length · scheme · live

Validate a URL against the spec

Q: Is anything sent to a server?

No — local validation. List of URLs stays in your browser.

Confirms a URL parses under WHATWG / RFC 3986, checks scheme, host, length and hygiene. All checks run in your browser.

URL Validator

Status

valid

parseable

Pass

checks

Fail

see report

Length

28 B

28 chars

input · url

output · report

OK Parseable URLConforms to RFC 3986 / WHATWG URL parser.

OK Protocolhttps:

OK Hostnameexample.com

FAIL Has IPv4 hostexample.com

FAIL Has port(default)

OK Uses HTTPSsecure

OK URL <= 2048 chars28 chars

OK Pathname <= 1024 chars5 chars

OK No surrounding whitespaceclean

Quick Start

How to validate a URL

Paste any URL — we run nine checks covering parseability, scheme, host, length and whitespace.

01
Paste a URL
Any scheme — https, http, ws, ftp, file, mailto.
Lookups reference the IANA registries (MIME, HTTP status, TLDs) bundled at build time — no live network calls, no rate limits, no leaked queries.
inputIANAregistryofflinelive
input · queryurl · IANA
```
https://example.com/...
```
loaded · IANA bundlespec · ready
02
Read parse result
If the WHATWG URL parser accepts it, the URL is well-formed.
Builders emit canonical syntax per the relevant RFC (9110 for HTTP, 5322 for headers, 3986 for URLs) so the output passes spec-compliant parsers.
parseRFC 9110canonicalspec-compliantlive
parse · optionsok · live
```
Parseable URL: OK
```
options applied · livecanonical
03
Check hygiene
Hostname, port, length, surrounding whitespace.
Validation flags common pitfalls — uppercase header names, smart quotes inside Content-Type, missing ;charset=utf-8 — before they bite production.
hygienevalidationlintpitfallslive
host · looked upok · ready
```
example.com → ok
```
result · livevalidated
04
Copy the report
Grab the full pass/fail report as text for issue tickets.
Copy writes the snippet directly into your clipboard; downloads emit the right extension and MIME so curl/httpie pick them up correctly.
copyclipboardMIME-correctblobcurl-ready
ok · copiedready · done
```
Copied report
```
shipped · ready to shipsuccess

Pro tips

Web-spec details that bite later

Idempotency saves retries

POST/PUT/DELETE should be safely retried. Use idempotency keys and return the same response on duplicate requests.

Match RFC 9110 status codes

Don’t invent codes. 422 for validation errors, 409 for conflicts, 429 for rate limits. Standard codes work with off-the-shelf clients.

Set <code>Cache-Control</code> deliberately

Default browser caching is conservative. Use max-age + stale-while-revalidate for hot endpoints.

Validate Open Graph in dev

OG tags break silently. Use a previewer like OG Generator + Facebook’s debugger before launch.

CORS is a server concern

The browser sends the preflight; the server decides. Wildcard origins disable credentials — be explicit.

MIME drives behaviour

Servers must send the right Content-Type. Browsers sniff but the spec says they shouldn’t — be explicit to avoid surprises.

Use Cases

When to validate a URL

Forms, integrations, security review.

Form validation

Sanity-check user-submitted URLs before storage. Bundled from IANA registries at build time — no live network call, no rate limit, no leaked queries. The MIME, TLD, and status-code tables are baked in so the tool works offline once loaded.

spec-compliant

Integration intake

Catch typos in webhook URLs before they fire. Output is canonical per the relevant RFC (9110 for HTTP, 5322 for headers, 3986 for URLs), so spec-compliant parsers accept it as-is. Cross-browser and cross-library behaviour stays consistent.

offline

Docs review

Confirm linked URLs are syntactically valid. Pairs with the curl-to-fetch converter for end-to-end test stubs — copy the curl from DevTools, paste, get an idiomatic fetch() body. Drop into Playwright/Vitest fixtures without manual translation.

IANA-backed

Config audit

Validate URLs in env files and YAML. Catches common pitfalls (uppercase header names, smart quotes inside Content-Type, missing ;charset=utf-8) before they bite production. Validation flags rather than auto-corrects so you stay in control.

RFC-aligned

Pre-deploy checks

Run as part of CI before pushing config. Validation runs as you type — copy only when the output is shaped correctly. The output drops directly into nginx, Apache, or CDN configs without re-formatting or re-quoting.

production-grade

Security review

Spot hostnames longer than expected or non-HTTPS. Same input plus same options always produces identical canonical output, so the tool is safe to embed in CI scripts that diff against expected configs.

curl-ready

FAQ

Frequently asked questions

Which spec do you check against?

The WHATWG URL Standard, which subsumes RFC 3986 for HTTP-style URLs.

Why flag non-HTTPS?

Modern apps should default to HTTPS. The check is informational and won't mark a URL invalid if it parses.

Is 2048 chars a hard limit?

No — many servers accept more. It's a common-sense ceiling for safe interop.

Are mailto:, javascript:, data: validated?

Yes — they parse, but you should still review them for safety.

Is anything sent to a server?

No — validation runs locally in your browser.

Suggest a tool

Something missing?

Tell us what you need. We ship the top requests every two weeks.

47 in queue·8 shipped this month

Request queued. Thanks!