Prioritize visible transport and header problems
Review the bounded security-header grade, HTTPS connection outcome, redirect result, and exact reasons before assigning fixes to the site's security owner.
Website Safety & Security Checker
Free, no signup. A practical security snapshot from public signals — useful for prioritizing fixes, never a penetration test.
Checks run from our server; we fetch the URL you enter and don't keep the results. This fetches a public page and security.txt. The optional Google Web Risk component is a blocklist advisory, not a live malware scan. No certificate-expiry claim is made. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.
Compare up to three URLs
Checks run sequentially and are not cached as a batch. Grades cover the same bounded public signals as the single check.
| URL | Grade | Score | Observed evidence |
|---|
Sample report
Illustrative example — deterministic complete public-signal fixture
A
Safety snapshot: 100/100
HTTP 200 · TLS handshake succeeded.
- Security headers: all scored header rules pass; COEP absence is informational only.
- Mixed content: no HTTP subresources or insecure form actions in the supplied HTML.
- security.txt: valid required fields found.
- Web Risk: not configured, so no malware/blocklist verdict is claimed.
This perfect fixture is intentionally narrow: it demonstrates scoring and is not described as a secure real-world website.
How to use it
- Enter the exact public URL and choose Run safety check.
- Read the overall letter as a summary of the implemented checks, then inspect the security-header grade and every reason.
- Distinguish a configured Web Risk advisory from checks marked not configured or not evaluated.
- Validate and prioritize changes with the site's security owner; do not use this report as a penetration-test substitute.
+ saves the current site or page. Use ☆ beside any saved site, page, or list to favorite it. Recent check history appears below.
Create a named list
Target filled from your local choices.
Site passport Local context for this saved site
Local data
Saved targets, named lists, and recent check summaries remain only in this browser.
Security headers
Public trust signals
Issues to review
This combines bounded public checks. It does not test authentication, application logic, vulnerabilities, malware behavior, certificate expiry, or every rendered resource.
Rate this tool
What the results mean
- A through F maps the numeric score into a summary band; it is not a risk certification.
- Security header grade comes from explicit pass, warning, error, and informational header rules.
- Issues to review lists every score reason plus security.txt and mixed-content evidence.
- Not configured or not evaluated is unavailable evidence, never a clean Web Risk verdict.
How it works
The endpoint fetches the public page, selected response headers, security.txt, limited RDAP data, and an optional Google Web Risk advisory. Shared deterministic functions scan bounded raw HTML for insecure subresources and form actions and validate required security.txt fields; the browser grades the returned evidence and combines those bounded signals into a documented score.
Features
- Security-header findings with exact remediation details.
- Raw-HTML mixed-content and insecure-form checks.
- security.txt validation and limited RDAP context.
- Optional Google Web Risk advisory with unavailable states preserved.
- Evidence-led score with explicit reasons.
- Sequential comparison of up to three public URLs.
Limitations
This is not a penetration test, vulnerability scan, certificate inspector, privacy audit, or live malware analysis. It does not execute JavaScript or inspect every rendered resource, application route, dependency, account control, server port, or security practice. A high score only describes the fetched public signals.
Frequently asked questions
Does an A grade mean a website is safe?
No. It means the bounded public checks scored well. The tool does not test application vulnerabilities, authentication, server configuration, malware behavior, social engineering, or data handling.
What does a Google Web Risk result mean?
When configured, it checks whether Google Web Risk returns a matching blocklist advisory. No match is not a live malware scan or a guarantee that a page is harmless.
Why does security.txt affect the score?
A valid security.txt gives researchers a standard way to report vulnerabilities. It is a useful public trust and response-readiness signal, but it does not make the application itself secure.
Can this checker see an expired certificate?
No. It records whether the HTTPS connectionHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.' completed, but the Worker interface does not expose certificate expiry, hostname coverage, chain, or cipher details.
What is mixed content?
Mixed contentMixed content is when a page served over HTTPS loads a sub-resource — a script, stylesheet, image, iframe, or similar — over insecure HTTP. Browsers' current taxonomy is upgradable versus blockable; active mixed content (scripts, styles, iframes) is blocked, and passive mixed content (images, audio, video) is warned about or increasingly auto-upgraded, with exceptions like CORS-enabled images and srcset/picture candidates that are blockable, not upgradable. occurs when an HTTPS page references an HTTP subresource or posts a form to HTTP. Those patterns can weaken transport protection and are detected only when visible in the fetched source.
Feature requests for Website Safety Checker
Upvote what you want most. New ideas can be submitted from the floating Feedback menu; requests appear here once approved, and the most-wanted rise to the top.
You won't be emailed about that request anymore.
Loading…
➕ Request a feature
New requests are reviewed before they appear here.
Where this tool helps
Common use cases
Find insecure resources and form actions in raw HTML
Surface HTTP subresources or form destinations that remain visible in the fetched source without claiming that every JavaScript-rendered resource was inspected.
Check public vulnerability-reporting readiness
Validate the required fields in security.txt as a public contact signal while keeping response readiness separate from application security.
Compare bounded safety signals across up to three URLs
Review representative production, staging, or template URLs sequentially and keep each grade tied to its observed HTTP, source, and security.txt evidence.
Create an evidence-led security handoff
Share the score reasons and unavailable states, then continue with authorized certificate, vulnerability, malware, application, privacy, and account-control testing where needed.
Watch the full workflow
Website Safety & Security Checker walkthrough
Read the transcript
Website Safety & Security Checker
This beginner walkthrough explains what Website Safety and Security Checker can observe, when to use it, how to run one complete fictional check, how to read the overall score and exact reasons, how to compare up to three U-R-Ls, and which important security questions remain outside the report.
Step 1
This checker creates a bounded safety snapshot from public evidence. It requests one exact page, reads selected response headers, scans the fetched raw H-T-M-L for insecure resources and form actions, checks security dot text, adds limited R-D-A-P context, and can include an optional Google Web Risk advisory. It then maps those implemented signals into a score and letter.
Step 2
Use the tool to prioritize visible transport and header problems, find insecure resources or form actions in fetched source, check public vulnerability-reporting readiness, compare the same bounded signals across up to three U-R-Ls, or create an evidence-led handoff for the security owner. Each use case starts a review; none replaces authorized security testing.
Step 3
Enter the exact public U-R-L and choose Run safety check. The disclosure explains that the server fetches the public page and security dot text and does not keep the result. It also states that Web Risk is a blocklist advisory, not a live malware scan, and that the tool makes no certificate-expiry claim. Those boundaries are part of the result.
Step 4
Open Compare up to three U-R-Ls to enter one public address per line. Bulk mode is useful for representative production, staging, or template pages. Checks run sequentially, are not cached as one batch, and use the same bounded evidence as the single checker. A difference between rows is evidence to investigate, not proof of the cause.
Step 5
The sample scores one hundred out of one hundred because every implemented fixture check passes. It still says Web Risk is not configured, and the page explicitly calls this example intentionally narrow. A perfect score describes the fetched public signals only. It does not certify a real website, its code, accounts, servers, users, or private systems as secure.
Step 6
The four-step workflow is straightforward. Enter the exact U-R-L. Read the overall letter as a summary, then inspect the separate security-header grade and every reason. Distinguish a configured Web Risk advisory from not configured or not evaluated. Finally, validate and prioritize changes with the security owner instead of treating the report as a penetration test.
Step 7
For the complete walkthrough, enter safety-demo dot example. Dot-example is reserved for documentation, so this is not a customer or public website. The capture fulfills both safety endpoints locally with fixed evidence and blocks every external response. That keeps the workflow realistic, repeatable, private, and identical across retakes.
Step 8
Choose Run safety check. The button shows that the request is running, then the result opens beneath the form. A live result can vary when the page, headers, security dot text, registration record, network path, or optional advisory changes. The fixed response here lets us focus on how to interpret the report.
Step 9
The fictional result is D, fifty-two out of one hundred. H-T-T-P two hundred means the page returned a response, and T-L-S handshake succeeded means an H-T-T-P-S connection completed. Neither statement means the site is secure. The D is a summary band for the implemented rules, so the next step is to read the evidence that produced it.
Step 10
Security headers receive a separate C, seventy-two out of one hundred. The result calls out a missing Content Security Policy and a missing Permissions Policy, with a plain-language reason for each. Cross-Origin Embedder Policy is also absent, but the text explains that it is informational because cross-origin isolation is not appropriate for every site.
Step 11
Public trust signals say Web Risk is not configured, security dot text is present but needs review, and R-D-A-P reports limited registrar and creation context. Not configured is unavailable evidence, never a clean blocklist verdict. Even a configured no-match would remain a blocklist advisory, not a live malware scan. Registration history also cannot prove that a site is safe.
Step 12
Issues to review lists one insecure H-T-T-P subresource, one form posting to H-T-T-P, and incomplete or expired security dot text with no valid Expires field. It also preserves the exact legacy script and form destination. Keep these reasons in the handoff. The mixed-content scan sees fetched raw H-T-M-L; it does not execute JavaScript or observe every rendered request.
Step 13
The result guide reinforces four distinctions. A through F is a numeric summary band, not a risk certification. The header grade comes from explicit pass, warning, error, and informational rules. Issues to review contains score reasons plus security dot text and mixed-content evidence. Not configured or not evaluated always means evidence was unavailable.
Step 14
The endpoint fetches the public page, selected response headers, security dot text, limited R-D-A-P data, and an optional Web Risk advisory. Deterministic functions scan bounded raw H-T-M-L and validate required disclosure fields. The browser grades the returned evidence and combines those signals into the documented score, while retaining the reasons needed to challenge or verify it.
Step 15
The main features are explicit security-header findings and remediation details, raw-H-T-M-L resource and form checks, security dot text validation, limited R-D-A-P context, an optional Web Risk advisory with unavailable states preserved, an evidence-led score, and sequential comparison for up to three public U-R-Ls.
Step 16
For the comparison, enter a narrow passing fixture, the fifty-two-point review fixture, and an unreachable fixture. These rows demonstrate three different outcomes without touching real sites. Use this pattern on representative pages only when you are authorized to test them, and keep each result tied to the exact U-R-L and check time.
Step 17
Choose Compare safety signals. The tool processes the U-R-Ls sequentially and then displays one evidence summary per row. In a live comparison, do not interpret a slower completion or a different grade without opening the exact single-page evidence. Bulk mode helps prioritize investigation; it does not add broader security coverage.
Step 18
The first row is A, one hundred, because its implemented fixture checks pass. The second is D, fifty-two, with H-T-T-P two hundred and security dot text needing review. The third is F, zero, because the page could not be fetched. The A is not a security certificate, the D needs its exact reasons, and the F is an observation that still requires network and ownership context.
Step 19
This checker is not a penetration test, vulnerability scan, certificate inspector, privacy audit, or live malware analysis. It does not execute JavaScript, inspect every route or dependency, test authentication or application logic, review account controls, scan ports, or see private infrastructure. Validate the visible findings with the security owner, rerun after fixes, and use authorized specialist testing for the risks that remain.
Use the score to start a review, not to end one
Save the exact U-R-L, check time, overall score, header grade, every reason, and every unavailable state. Fix the visible H-T-T-P resource, form, header, and security dot text issues with the site owner, then verify the changes. Continue with authorized certificate, vulnerability, malware, application, privacy, account-control, and infrastructure testing wherever the risk calls for it.
Common issues & how to fix them
- Error Page is not served over HTTPS Fix: Serve the page and all canonical assets over HTTPS, then redirect HTTP requests directly to the HTTPS URL.
- Error HTTPS page loads an insecure resource Fix: Replace every HTTP subresource with a working HTTPS URL or remove the insecure dependency.
- Error Form submits to an insecure URL Fix: Change the form action to an HTTPS endpoint and confirm no redirect sends submitted data back over HTTP.
- Warning Protective security header is missing Fix: Add the specifically reported protective header at the origin or edge with a policy tested against the site’s required resources.
- Error TLS certificate signal needs attention Fix: Repair or renew the certificate and TLS chain, then confirm the HTTPS handshake succeeds.
- Error Safe URL redirects to an insecure destination Fix: Keep every redirect hop and the final destination on HTTPS.