Web Tools
Test how a site presents itself to browsers: whether HTTPS works, how long its certificate lasts, where redirects lead and which security headers it sends. Each result links to a plain explanation and a safe way to fix it.
Web Tools directory
Check whether a website answers over HTTPS, from which addresses, with what status, final URL, TLS version and timing, and whether the certificate is trusted.
Find out how many days remain on a website's HTTPS certificate, see every certificate the server sends, and tell expiry apart from hostname or chain problems.
See which TLS versions a server accepts, the negotiated protocol and cipher, and the full certificate chain with names, validity, key and signature details.
Trace every hop from HTTP to HTTPS, see status codes and Location headers, and detect downgrades to HTTP, loops and redirects that leave the domain.
Parse the Strict-Transport-Security header, see which host it protects, and review preload eligibility with the cautions that come with includeSubDomains.
Parse a site's Content-Security-Policy into a directive table, separate enforced from report-only, and flag risky sources like unsafe-inline and wildcards.
Find out whether other websites can embed your page in a frame by checking X-Frame-Options and CSP frame-ancestors, and spot conflicting or obsolete values.
Check whether a site sends X-Content-Type-Options: nosniff, which stops browsers guessing file types, and the Content-Type it depends on.
See which Referrer-Policy a site sends, how much of the page URL is shared with other sites, and why unsafe-url or no-referrer-when-downgrade are flagged.
Review the Permissions-Policy header to see which browser features such as camera, microphone and geolocation your site and its embedded content may use.
Review seven HTTP security headers on a site's landing page in one table, with a verdict for each, plus cross-origin and caching notes. No score is given.
Check for a security.txt file at the standard location, validate its Contact and Expires fields, and see how to give researchers a safe way to report issues.
What the web tools observe
Every tool on this page starts from the same observation: the domain is resolved, and its site is requested over HTTPS from the apex or www host. The tools differ in what they extract. Some look at the transport (reachability, protocol versions, certificate dates, redirects), others at the response headers that tell browsers how to behave. Because they share one observation they agree with each other and with the domain assessment.
The requests are honest: the checker identifies itself and does not imitate a browser, so sites that block automated clients may show different behaviour. Only the landing page is examined.
Transport and certificate tools
Start here if visitors see browser warnings or the site is unreachable.
- HTTPS Checker: reachability per address, final URL, status and timing.
- TLS Checker: which of TLS 1.0 to 1.3 are accepted and what the certificate chain contains.
- SSL Certificate Expiry Checker: days remaining, with thresholds, and the difference between expiry and chain or hostname faults.
- HTTP Redirect Checker: every hop from HTTP to the final page, with downgrade and loop detection.
Header tools
Response headers are low-cost defensive layers. None of them is a score or a guarantee.
- HSTS Checker: Strict-Transport-Security, scope, and preload eligibility with its cautions.
- CSP Checker: directives, enforced versus report-only, and risky sources.
- Security Headers Checker: seven headers in one table.
- Clickjacking Checker, MIME Sniffing Checker, Referrer Policy Checker and Permissions Policy Checker: one header family each.
- security.txt Checker: whether researchers have a valid contact.
Reading results with the right expectations
A passing header check means the header is present and sensible, not that the site is secure. Application bugs, weak passwords and unpatched software are outside what response headers can address. Equally, a missing header is an opportunity, not an emergency: the tool names a severity, and most are low. Change headers one at a time, starting with the least disruptive, and keep a rollback value ready, because strict policies such as CSP and HSTS can break features when applied carelessly.
A sensible order of work
When a site misbehaves, work from the outside in. Confirm that HTTPS answers on every address, then that the certificate is valid and complete, then that HTTP redirects cleanly to the final HTTPS host. Only after transport is sound is it worth tuning HSTS, which locks that transport in. Headers such as CSP, framing and referrer policy come last, because they refine behaviour that already works. Following this order avoids the common mistake of enabling a strict policy on top of a transport problem and then blaming the policy.
Written by DNS Tools editorial · Last updated 2026-10-09