Fake Checker Tools on the Web: SSL, Redirects, Headers, OG, Robots

The CORS Reality: Why a Frontend Cannot Fetch Arbitrary URLs

Open any modern browser. Open the developer console. Type fetch('https://example.com') and press enter. You will see a CORS error: "No 'Access-Control-Allow-Origin' header is present on the requested resource." This is not a bug. This is the entire web security model working correctly.

The Same-Origin Policy, formalised in the 1990s and refined in the WHATWG Fetch specification, prevents JavaScript from reading the response of a request made to a different origin (different protocol, domain, or port) unless the target server explicitly permits it via CORS headers. Without this rule, any malicious site you visit could read the contents of your bank's web pages, your email inbox, your company's internal admin tools — anything your browser is currently authenticated to. The Same-Origin Policy is the reason this catastrophe does not happen.

The practical consequence: a static frontend tool, served from one domain, cannot fetch the headers, content, or metadata of an arbitrary URL on a different domain. It cannot check whether example.com has a valid SSL certificate. It cannot trace redirects from bit.ly/abc to its destination. It cannot read the response headers of some-blog.com. It cannot fetch their-site.com/robots.txt. It cannot parse news-site.com's Open Graph tags. None of this is possible from JavaScript running in the user's browser, regardless of how the UI presents the result.

There are exactly three ways for a tool to legitimately do these things. Option A: a backend. The frontend sends the URL to a server (Node, Go, Python, whatever), the server makes the request from its own IP without browser CORS restrictions, and returns the result to the frontend. This requires server infrastructure, costs money to run, and creates a privacy decision (the user's URL is sent to a third-party server). Option B: a CORS proxy. A free public CORS proxy like corsproxy.io or allorigins.win acts as a middleman. The frontend fetches through the proxy. Same privacy implications, plus dependency on a free service that may rate-limit or shut down. Option C: a browser extension. Extensions can request elevated permissions to bypass CORS for specific origins. Most "checker" tools are not extensions because the install friction kills conversion.

Any free in-browser checker tool that promises to fetch arbitrary URL metadata without any of the three above is lying. The most common implementation is the fourth option: option D, fake the result entirely.

Five Categories of Fake Checker Tools

The pattern is the same across categories. The frontend collects your URL, shows a loading spinner via setTimeout(() => setLoading(false), 1500), then renders a result based on hardcoded mock data, the URL string itself, or extremely shallow heuristics. Here are the five most common fakes you will encounter on the free-tool web.

1. Free SSL Checkers

What they claim: "Check the SSL certificate of any website. Verify expiry date, issuer, signature algorithm, and chain validity."

What they actually do: The browser cannot read SSL certificate details for a third-party domain — the certificate is exchanged during the TLS handshake before any HTTP-level access. There is no JavaScript API to inspect a foreign certificate. Tools that claim to do this in the browser either (a) call a backend that you cannot see, (b) call a CORS proxy and only return whether the URL responded with HTTPS at all, which is trivial and does not require a "checker", or (c) generate fake certificate data based on the URL.

The smell test: Type https://expired.badssl.com into the tool. This is a real test domain maintained by Google with a deliberately expired certificate. A real SSL checker correctly reports the certificate as expired since 2015. A fake tool will either time out, claim the certificate is valid, or return generic placeholder data ("Certificate Authority: Let's Encrypt, Expires in 90 days") regardless of input. Try it on a few badssl.com test domains — wrong host, self-signed, untrusted root — and watch how the tool responds. A real checker distinguishes them. A fake one returns the same result every time.

Use instead: SSL Labs SSL Server Test by Qualys is the industry standard. It runs a full TLS handshake from their servers, tests cipher suite compatibility, simulates 50+ client browsers, and grades the configuration A+ to F. Slow (typically 60-120 seconds per scan) but exhaustive. For command-line use, openssl s_client -connect example.com:443 -servername example.com dumps the full certificate chain. crt.sh queries Certificate Transparency logs to show every cert ever issued for a domain — useful for spotting unauthorized issuance.

2. Free Redirect Checkers

What they claim: "Trace the full redirect chain of any URL. See every 301/302 hop with status codes and final destination."

What they actually do: Browser fetch() follows redirects automatically by default and does not expose intermediate hops to JavaScript. Even with { redirect: 'manual' }, you get an opaque-redirect response with no visible status code or headers due to CORS. A real redirect tracer must run on a server. Frontend-only tools either (a) fake the chain by parsing the URL itself for bit.ly-style patterns, (b) call an undisclosed backend, or (c) call a CORS proxy that strips the actual redirect information, leaving them to invent a plausible-looking chain.

The smell test: Submit a URL with a known multi-hop redirect chain you control — for example http://yourdomain.com/test redirecting to https://yourdomain.com/test redirecting to https://www.yourdomain.com/final. A real tracer reports all three URLs and the two 301 status codes. A fake tool typically reports either one hop or the full destination with no intermediate steps, because it cannot actually see the chain.

Use instead: curl -sIL https://example.com on the command line dumps every hop with its status code, in 200ms. The -I flag fetches headers only, -L follows redirects, -s silences progress. For a graphical tool, httpstatus.io is server-backed and free for low-volume use. Browser DevTools Network tab also shows the full chain when you load a URL — disable "Preserve log" and click the URL, every redirect appears as a separate row with status code.

3. Free HTTP Header Inspectors

What they claim: "View all HTTP response headers for any URL. Inspect security headers, caching policies, server fingerprints."

What they actually do: Without CORS permission from the target server, the browser exposes only a tiny whitelist of "CORS-safelisted response headers" (Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, Pragma) and only when the request itself completes. Security headers like Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, Referrer-Policy — exactly the headers anyone wants to inspect — are not visible to JavaScript without explicit CORS permission, which third-party sites do not grant to your random checker tool. So frontend-only header inspectors either show a useless subset, fabricate plausible values, or proxy through a backend.

The smell test: Submit a URL and check whether the tool reports the Server header — for example nginx/1.24.0 or cloudflare. The Server header is not on the CORS safelist, so a pure browser implementation cannot read it. If the tool claims to know the server software, it is either using a backend (legitimate) or guessing from other signals. Also try a URL with a deliberately weird header (set up your own test endpoint that returns X-Custom-Test: 42) and see if the tool surfaces it. A real proxy-backed tool does. A fake one shows generic header sets.

Use instead: curl -I https://example.com dumps every response header in one line. Browser DevTools Network tab shows full headers for any request your browser makes — visit the URL, click the request, view the Headers tab. Mozilla Observatory and Scott Helme's securityheaders.com are server-backed scanners that grade security header configuration A+ to F. Hardenize covers TLS, security headers, DNS, email, and more in a single scan.

4. Free Open Graph / Social Card Validators

What they claim: "Preview how your URL will look when shared on Facebook, Twitter, LinkedIn. Validate Open Graph and Twitter Card tags."

What they actually do: Reading another site's Open Graph tags requires fetching its HTML and parsing the head. CORS blocks this from the browser. Frontend-only OG checkers proxy through a free service (often allorigins.win, which has a daily quota and occasionally serves stale or rate-limited responses) or generate the preview from URL guesses. The smarter ones use open-graph-scraper on a backend you cannot see; the lazy ones return a stock preview based on the domain.

The smell test: Submit a URL on a site you control where you have set deliberately weird OG values (og:title = "TEST_VALUE_12345"). A real fetcher returns your test value. A fake one returns the page's <title> tag, the domain name, or generic placeholder text. Also try a URL behind authentication or with no OG tags at all — a real fetcher returns "no OG tags found", a fake one fabricates plausible ones.

Use instead: Meta's Sharing Debugger for Facebook and Instagram previews — also clears Meta's preview cache, which is the only way to refresh outdated previews. Twitter's Card Validator is officially deprecated but still functional for X previews — alternatively use opengraph.xyz, which is server-backed and shows previews for Facebook, X, LinkedIn, Slack, Discord, iMessage in one shot. LinkedIn's Post Inspector handles LinkedIn previews and cache busting.

5. Free robots.txt Validators

What they claim: "Test whether Googlebot can crawl any URL on any site. Validate robots.txt syntax. Check disallow rules."

What they actually do: Fetching example.com/robots.txt from a third-party domain hits the same CORS wall as everything else. Most robots.txt by convention serve Access-Control-Allow-Origin: * because it is a public file, but plenty do not — Cloudflare's default does, Vercel's varies, AWS S3 static hosting often does not. Frontend-only tools that work for some sites and time out on others are using direct fetch() and silently failing on the ones without permissive CORS. Tools that work universally are using a backend or CORS proxy.

The smell test: Try the tool on example.com/robots.txt (which sets permissive CORS) — it works. Try it on a domain you have configured to serve robots.txt without Access-Control-Allow-Origin — a frontend-only tool fails or invents a default "User-agent: * / Allow: /" result. A real backend-based tool fetches and shows the actual file. The fake tools that try to look smart by parsing your URL's path against an imagined ruleset are particularly egregious.

Use instead: Google's robots.txt Tester in Search Console runs the actual Googlebot parser against your robots.txt and tells you whether a specific URL is crawlable. TechnicalSEO.com's robots tester is server-backed and free. For local validation, curl https://example.com/robots.txt shows the file, and you can mentally validate against the RFC 9309 Robots Exclusion Protocol standard. The Google open-source robots.txt parser is the reference implementation.

How to Spot a Fake Checker Tool Before Wasting Your Time

The 60-second checklist. Run these tests on any free in-browser checker before you trust its output.

1. Open the network tab and watch what happens when you click the check button. If you see zero outbound requests, the tool is generating its result entirely from the URL string and hardcoded data — not actually checking anything. If you see one request to a CORS proxy (typical hosts: allorigins.win, corsproxy.io, thingproxy.freeboard.io), the tool is real but limited by the proxy's capabilities and quotas. If you see a request to a backend on the tool's own domain, the tool has real infrastructure — usually a good sign.

2. Submit a URL designed to break the tool. For SSL: https://expired.badssl.com. For redirects: a chain you control with three or more known hops. For headers: a URL behind authentication that returns 401. For OG: a URL with no OG tags at all. For robots.txt: a URL that returns a 404. A real tool reports the actual condition (expired, 401, missing, 404). A fake tool returns a plausible-looking generic result, often with "no issues found" — because it never actually fetched anything.

3. Submit the same URL twice with a different protocol or trailing slash. A real tool returns different results for http:// versus https://, or for example.com/page versus example.com/page/. A fake tool returns identical results because it is hashing the domain or ignoring the path entirely.

4. Look at the loading time. A real check, even a fast one, takes 200ms-3s depending on the target server. If the result appears in exactly 1.5s every time regardless of the URL, that is setTimeout(..., 1500) theatre. Real network requests have variable latency. Fake ones do not.

5. Check the privacy policy and terms. A tool that genuinely makes server-side requests usually mentions it (sometimes proudly, as a feature; sometimes defensively, in the privacy policy). A tool that processes "everything in your browser" while claiming to fetch arbitrary URLs is contradicting itself — the architecture is not possible. Believe the architecture, not the marketing.

The Practical Takeaway

The web's free-tool ecosystem is full of "checkers" that cannot do what they claim. Browser security correctly prevents them from fetching arbitrary URL metadata, so they fake the output instead. The result looks professional, takes 1.5 seconds, and tells you essentially nothing. Most users do not notice because they do not know to test.

For the categories covered above — SSL, redirects, headers, Open Graph, robots.txt — there are real, free, server-backed alternatives, often run by the platforms themselves (Google, Meta, Mozilla, Qualys). Use them. They take a few extra clicks to find but they actually do what they claim.

And for one-off checks, curl and the browser DevTools Network tab handle 90% of the use cases in seconds. The single command curl -sIL -H "User-Agent: Mozilla/5.0" https://example.com tells you the redirect chain, every status code, and every response header — replacing four or five separate "checker" tools at once. Learn it. Stop trusting tools that physically cannot do what they claim.