Website Checker

One hostname in, the whole web-layer picture out: DNS, redirect chain, TLS certificate, security headers, HTTP/2 + HTTP/3, transport timings. Cross-checks against your existing tools so you don't have to open seven tabs.

Try an example: github.com · tamingdns.com · cloudflare.com · badssl.com

How this website checker works

Type a hostname and the checker walks the path a browser would. It resolves A and AAAA over DoH, reverse-resolves each IP, looks up the ASN, then opens HTTPS on port 443 and follows every redirect by hand so each hop gets re-validated for SSRF. The final response gives us the security headers; the TLS socket gives us the certificate, the negotiated TLS version and the cipher.

What the chips actually mean

Every probe gets its own chip. No letter grade. A site can ace TLS and still miss HSTS; rolling that into one letter hides the thing the developer needs to fix. The signal chips read: 

✓  passes the check
⚠  present but weak (HSTS without includeSubDomains, CSP with unsafe-inline)
✗  missing or broken
·  not applicable / not measured

Our take: use the chips as a triage row. Fix the ✗ first, tighten the ⚠ next sprint, leave the ✓ alone.

What this tool deliberately doesn't do

We don't run a deep CSP analyser. A shallow CSP scorecard is worse than no scorecard, so we check two things: is a header present, and does it allow 'unsafe-inline' in default-src or script-src. For anything beyond that, run your policy through a dedicated CSP evaluator.

We don't do a full QUIC handshake. HTTP/3 is detected from the Alt-Svc: h3= header on the HTTPS response, which is the same signal a browser uses to try QUIC next time. If the chip says "HTTP/3 advertised" the site is offering it; whether your specific network can actually reach UDP/443 is a separate question.

And we probe from one vantage point. GeoDNS-fronted sites will look different from other regions. If the result looks wrong, run the same hostname through DNS propagation first to see whether different resolvers are returning different IPs.

Where to go next

Every related tool is linked at the bottom of the results, with the hostname pre-filled. A few patterns come up often: 

TLS clean here, browser warns      →  cross-signed root the OS dropped
Redirect ends on a host you didn't  →  check the apex CNAME
expect
TLS fine, headers row mostly red    →  it's the edge / CDN, not the origin

Frequently Asked Questions

Common questions about reading this scan.

The checker confirms the chain validates against the public CA store on this server. Browsers carry their own trust stores, and they're not the same set. A cross-signed intermediate that this server still trusts can already be removed from Chrome or Firefox.

OCSP stapling, Certificate Transparency logging, and OS-level pinning all sit outside what this tool measures. If a browser warns and the chip is green, the next steps are: open the offending site in openssl s_client -connect host:443 -servername host, compare the chain to what the browser shows, and look at the CA's recent advisory list.

Our take: the chip means "the certificate parses, the chain builds, the SAN covers the host, the expiry is in the future." It does not mean "every browser on Earth trusts it."

Detection runs over TCP. We open HTTPS, read the response, and look for an Alt-Svc header announcing an h3 endpoint. That's the same trigger a browser uses to try QUIC on its next visit.

A real HTTP/3 confirmation needs a UDP handshake from a vantage point that can reach the QUIC port (UDP/443 by default). That's a more involved probe, and a lot of corporate networks block UDP/443 anyway. We left the actual QUIC test for a future tool rather than ship a check that lies on locked-down networks.

We check two things: is a Content-Security-Policy header set, and does it contain 'unsafe-inline' in default-src or script-src. If both are clean the chip goes green; if either is missing it goes amber or red.

That's a deliberately shallow check. Full CSP analysis is a discipline of its own: nonces vs hashes vs strict-dynamic, allowlist hygiene, fallback directives, the difference between script-src and script-src-elem. A green chip from us doesn't replace a CSP evaluator.

What to do: if you've genuinely got a tight CSP, ignore the chip colour and run the policy through a dedicated evaluator. We err on the side of "remind the developer to look" rather than rubber-stamp.

Usually no. Most production sites bounce example.co.za to www.example.co.za, or apex to a CDN landing page, or a country TLD to a global one. The chain panel shows every hop, every status, every TTFB, so the path is auditable.

Where it gets interesting: if a hop drops from HTTPS to HTTP (anywhere except the very first 301), the chain is leaking. Mixed-mode redirect chains break HSTS preload and let a network attacker downgrade the first request. Browser dev tools hide them. The hop table here doesn't.

One vantage point. The scan runs from the TamingDNS server, which is one specific IP, in one specific country, on one specific ASN. Three things commonly fork the result from what your laptop sees:

GeoDNS  →  the apex resolves to a different IP for us than for you
WAF     →  the origin blocks the User-Agent, ASN, or country we're in
Routing →  a transit issue between our network and the origin

Cross-check by running DNS propagation for the same hostname. If different resolvers return different IPs, GeoDNS is the cause and the scan is working as intended; the IP we hit just isn't healthy.

No. SSL Labs digs into the TLS handshake at a level we don't: cipher preference ordering, downgrade tests, every protocol version, CT log posture. Mozilla Observatory grades headers with a much deeper rubric than ours.

What you get here is triage. One hostname in, every web-layer signal in one pass. When a chip goes red and the answer below isn't enough, open the specialist.

Our take: use this to find which layer is broken. Use the specialists to fix it.

📋 Want to see the underlying record types? DNS Record Type Reference →