How to Check If a Website Is Safe: The 2026 Checklist

You landed on a site you've never used before, maybe from an ad, a search result, or a link someone sent you, and now you're hesitating before typing in an email address or a card number. Learning how to check if a website is safe does not require a computer science degree or a paid subscription. It takes about five minutes with tools already built into your browser.

This post walks through the checks anyone can run on any website: the padlock icon, the domain's age, who runs the site, what other people say about it, and whether it shows up on a malware or phishing blocklist. Each one is quick, and together they catch most scam and phishing attempts.

If the website in question is one you built yourself, maybe with an AI coding tool, these visitor-facing checks only tell part of the story. The risks that actually cost founders their user data are invisible from the outside: a missing database permission, a secret key sitting in your app's public code, a storage folder anyone can browse. This post covers both, starting with what any visitor can check today.

⚡ TL;DR

• A padlock (HTTPS) proves the connection is encrypted. It says nothing about whether the business behind it is trustworthy.
• Domain age, contact info, real reviews, and blocklist status are the fastest signals for checking a site you don't run yourself.
• If it's your own app, those visitor-facing checks miss what actually matters: missing database permissions, secret keys shipped in your browser code, and open storage buckets.
• A public Supabase anon key or Firebase web config showing up in your source is not a leak. A checker that flags it as critical is crying wolf.

How to check if a website is safe: the signals anyone can see

These five checks work on any website, whether you're about to enter a card number at checkout or want a second opinion before you sign up.

1. HTTPS and the padlock icon

Every browser shows a padlock, or a "not secure" warning, based on whether the connection uses HTTPS, which encrypts the data traveling between your browser and the server. Click the padlock in your address bar and confirm the connection is secure before typing in anything sensitive.

But the padlock only proves the connection is encrypted, not that the site behind it deserves your trust. Certificates are free and automatic to obtain, so a scam page can carry the same padlock as your bank. Treat it as a minimum bar, not a verdict.

2. Domain age and lookalike URLs

Scammers rarely invest in aged domains, and they often mimic a real brand with a small twist. A domain registered a few weeks ago, or one that looks like "paypa1.com" or stacks a fake subdomain in front of a real name ("paypal.com.verify-login.net"), is a red flag.

How to check: search "whois lookup" plus the domain name to see its registration date, and read the URL itself letter by letter for the tricks above. If you're deciding whether to click a link at all rather than a full site, checking whether a link is safe before you click it walks through the same tricks in more detail.

3. Contact information and a real terms of service

Legitimate businesses want to be found and are willing to be held to something in writing. A site with no way to reach a real person, no address, and no terms of service or privacy policy is a business avoiding accountability.

How to check: look for footer links to "Contact," "About," "Terms," and "Privacy." Read the terms for an actual company name and jurisdiction, not filler text copied from a template.

4. Reviews and reputation

A brand with real customers usually has a visible trail of opinions about it, good and bad, spread across places it doesn't control.

How to check: search the brand name plus "review" or "scam" and look at results outside the company's own site: forums, independent review sites, social posts.

5. Malware and phishing blocklists

Browsers and security vendors maintain shared lists of known bad domains and check every site you visit against them automatically.

How to check: most modern browsers already do this in the background. For a manual second opinion, paste the URL into your browser's own site-status page or a reputable blocklist lookup tool before you visit an unfamiliar link.

The catch: these are the signals a visitor can see

Every check above happens from the outside. A visitor, or a scanner acting like one, reads what's publicly told to them: the certificate, the registration record, the page footer, public opinion, and a blocklist. None of it looks inside the app.

That's enough for deciding whether to trust someone else's checkout page. It is not enough if the website is yours, especially if it was built with an AI coding tool that writes the backend along with the frontend. The risks that actually leak user data live somewhere a padlock check can't reach: your database's access rules, the code shipped to every visitor's browser, and the storage buckets holding uploaded files.

How to check your own app

If you're the one who shipped the site, run these checks instead. None of them require reading code.

1. Database access rules. If you're on Supabase, open your dashboard, go to the table editor, and confirm Row Level Security (RLS), a per-user filter the database enforces on every query, is turned on for every table holding real user data. A policy that reads USING (true) lets everyone through, which is the same as no policy at all. A closer look at this exact check covers how to read a policy correctly.
2. Secret keys in your shipped code. Open your live site, view source or your browser's dev tools, and search your JS bundles for sk_live_ (a Stripe secret key), service_role (Supabase's RLS-bypass key), or a raw OpenAI/AWS key. None of those belong in a browser.
3. Storage buckets. Copy the direct URL of a private uploaded file, a profile photo or a document, and open it in a logged-out private window. If it loads without asking you to sign in, the bucket isn't locked down.
4. Response headers. From a terminal, run:

curl -I https://yourdomain.com

Check the output for Content-Security-Policy, X-Frame-Options, and X-Content-Type-Options. Missing headers are common and cheap to fix once you know they're missing.

For a fuller version of this walkthrough with a yes-or-no verdict at the end, see the 10-minute safe-to-ship check, or the complete vibe coding security guide for the section-by-section version.

Why a public Supabase key or Firebase config isn't the leak

🐺 Not a real problem

If a checker (or a curious teammate) flags your Supabase anon key or your Firebase web config, the apiKey and friends, as an exposed secret, it's wrong. Both are meant to sit in your browser code. That is how those platforms are designed to work.

The real risk sits one layer deeper: whether the database rules behind that anon key actually restrict rows to their rightful owner, and whether Firebase Security Rules do the equivalent job for a Firebase backend. A key on its own does nothing if the door behind it is closed.

This matters because a number of both free and paid website checkers get it backwards: they see a key-shaped string in a JS bundle and mark it critical, a founder spends an afternoon "rotating" a key that was never meant to be secret, and the actual issue, permissive database rules sitting right behind it, never gets a second look.

FAQ

Does a padlock (HTTPS) mean a website is safe?

No. The padlock means the connection is encrypted, not that the business behind it is trustworthy. Free certificates are available to anyone, including scam sites. Use it as one signal among several, not a verdict on its own.

What's the fastest way to check if a website is safe before entering personal information?

Check the padlock, read the URL for lookalike tricks, and search the brand name plus "scam" in a separate tab. Those three take under a minute and catch most obvious scams. For a specific link, check it before you click.

My own scanner flagged my Supabase anon key or Firebase config. Do I need to fix it?

No. Both are public by design and meant to ship in browser code. A scanner that treats that as critical is crying wolf; the real question is whether your database rules (RLS or Firebase Security Rules) actually restrict access behind that key.

How often should I re-check my own app?

Every time you or your AI tool ships a change that touches authentication, data, or file uploads. A one-time check is a snapshot; new code can quietly reopen a gap you already closed.

The bottom line

Checking if a website is safe, someone else's or your own, comes down to reading signals the site can't hide: the connection, the domain, who's behind it, and what it exposes to the outside. For a site you're visiting, HTTPS, domain age, contact info, reviews, and a blocklist check cover most of it. For a site you built, the real risks (missing RLS, secret keys, open buckets, missing headers) sit below what any visitor ever sees, and your AI ships new code, and potentially new holes, on every deploy. Running a free website security scan on your own app on a regular cadence turns a one-time check into a habit.