Inventory visible technology before a redesign or migration
Document supported CMS, framework, CDN, ecommerce, analytics, JavaScript, and font fingerprints on representative public templates.
CMS & Tech Detector
Free, no signup. Inspect a public page for visible CMS, framework, CDN, ecommerce, analytics, JavaScript, and font fingerprints — with the exact evidence that fired.
The HAR is parsed locally and is not uploaded. Request bodies, cookies, headers, and query values are not retained by tag inventory.
Checks run from our server; we fetch the URL you enter and don't keep the results. We fetch the URL you enter; the detector runs in your browser. Optional HAR parsing stays in this browser tab. 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.
Sample report
Illustrative example — deterministic supported signatures
For HTML containing <meta name="generator" content="WordPress"> and asset paths under /wp-content/, the detector reports:
WordPress high confidence · CMS
Evidence: the generator fingerprint and WordPress asset-path fingerprint both matched.
A single supported fingerprint would be medium confidence. No match would produce an explicit “no signatures matched” message, not a claim that the page uses no technology.
How to use it
- Enter a public page URL, ideally a representative page rather than a login screen.
- Choose Detect stack and review each technology, category, confidence, and evidence string.
- Confirm important detections in source, response headers, or the platform itself before acting on them.
- Check more than one template when a site may use different technology by section.
Site passport Local context for this saved site
Local data
Saved targets, named lists, and recent check summaries remain only in this browser.
Visible fingerprints
Tag inventory evidence
Rate this tool
How to read the result
- High confidence means more than one signature for that technology matched.
- Medium confidence means one supported signature matched.
- Evidence names the signature rules that fired; it should be reviewed before treating a detection as fact.
- No signatures matched means only that the current raw HTML and selected headers lacked a known signal.
Data sources & freshness
The server fetches public HTML and a selected response-header map. In the browser, the detector lowercases those values and compares them to a curated JSON signature list covering HTML substrings, generator metadata, headers, and supported cookie names. Matches are grouped by technology and sorted by category and name.
Features
- CMSA content management system (CMS) is software that lets users create, manage, and publish digital content — like blog posts and pages — without writing raw code. WordPress, Drupal, and Joomla are the most common open-source CMS platforms., framework, CDN, ecommerce, analytics, JavaScript, and font categories.
- Exact evidence for every detection.
- Two transparent confidence levels based on match count.
- Browser-side matching after the public fetch.
Limitations
The checker does not render JavaScript, scan a whole site, identify private infrastructure, verify versions, or test vulnerabilities. Proxies, tag managers, cached markup, and removed or spoofed fingerprints can cause false negatives or false positives.
Frequently asked questions
How does a technology detector identify a CMS or framework?
It matches public fingerprints in raw HTML and selected response headers against a maintained signature list. The report shows the exact signal that matched so you can judge it.
Why did the detector miss a technology I know the site uses?
A site can remove generator tags, proxy assets, rename paths, render signals with JavaScript, or hide origin headers behind a CDN. No match means no supported public signature was observed, not that the technology is absent.
Can a tech-stack detection be wrong?
Yes. Public strings can be shared, stale, or spoofed. One matching signal is medium confidence; multiple supported signals raise confidence, but neither is proof of the complete production stack.
Is this a vulnerability scanner?
No. It does not test versions, vulnerabilities, ports, authentication, or application behavior. It only reports supported public fingerprints.
Feature requests for Tech Stack 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
Verify analytics and tag-loader evidence
Combine raw HTML with an optional local HAR file to see supported DOM and request fingerprints without retaining request bodies, cookies, headers, or query values.
Compare technology across site sections
Run representative product, article, category, and regional pages separately when one domain may use different stacks by template or subdomain.
Investigate a missing or uncertain detection
Treat one match as medium confidence and no match as missing supported public evidence, then review source, headers, rendered behavior, or the platform itself.
Create an evidence-backed implementation handoff
Share the exact fingerprints that fired while keeping visible-stack detection separate from version checks, vulnerability testing, private infrastructure, and whole-site proof.
Watch the full workflow
CMS & Tech Detector walkthrough
Read the transcript
CMS & Tech Detector
If you are new to technology detection, this walkthrough will show you what CMS and Tech Detector can actually prove. We will cover useful situations, the page and optional H-A-R inputs, a complete fictional example, every result field, how confidence works, tag evidence, privacy, limitations, and the checks to make before you act on a detection.
Step 1
CMS and Tech Detector inspects one public page for visible fingerprints from content-management systems, frameworks, content-delivery networks, ecommerce platforms, analytics tools, JavaScript libraries, and fonts. It reports the supported evidence that fired. Think of it as a fast, evidence-backed inventory of public signals, not a complete map of everything running behind the site.
Step 2
Common use cases include documenting visible technology before a redesign or migration, checking analytics and tag-loader evidence, comparing the stack on product, article, category, or regional templates, investigating a missing or uncertain detection, and preparing an implementation handoff. The important habit is to keep the fingerprint beside the technology name so the next person can review why it appeared.
Step 3
The required input is a public page U-R-L. Choose a representative public template instead of a login screen. The optional H-A-R file adds bounded request evidence from a browser network export. The site fetch runs through this site’s bounded server endpoint, while H-A-R parsing stays in this browser tab. The inventory does not retain request bodies, cookies, headers, or query values.
Step 4
The sample report introduces the confidence model. WordPress reaches high confidence when more than one supported fingerprint matches, such as generator metadata and a WordPress asset path. One supported fingerprint would be medium confidence. If nothing matches, the tool says no signatures matched; it does not claim that the page uses no technology.
Step 5
The workflow is straightforward. Enter a representative public page. Select the button labelled "Detect stack". Review every technology, category, confidence level, and evidence string. Then confirm important detections in source, response headers, or the platform itself. If a site can use different technology by section, repeat the check on more than one representative template.
Step 6
For a safe full example, load a small fictional H-A-R file. The status confirms that two bounded request candidates were loaded locally. Then enter stack-demo dot example, a reserved fictional address. During this capture, the page response is fulfilled by a local fixture and every external response is blocked, so no real site, analytics vendor, or tag endpoint is contacted.
Step 7
Select "Detect stack". The status changes to "Done" when the local fixture returns raw H-T-M-L and a small selected response-header map. The browser compares those values with the supported signature list and combines them with the local H-A-R candidates. The result then opens on visible fingerprints, followed by separate tag-inventory evidence.
Step 8
This fictional page produces five visible-technology results. Google Analytics four, Google Tag Manager, Cloudflare, and WordPress each have high confidence because multiple supported signals matched. jQuery has medium confidence because one supported signal matched. Each card also names a category and the exact rule evidence, such as a generator tag, asset path, script substring, or selected response header.
Step 9
Confidence describes the number of supported signatures, not certainty about the whole production system. High means more than one rule matched for that technology. Medium means one rule matched. A match can still come from cached, proxied, shared, stale, removed, or spoofed markup. No match can simply mean that the current raw H-T-M-L and selected headers do not expose a known signal.
Step 10
The evidence strings are what make this report useful for a handoff. WordPress shows generator and asset-path clues. Cloudflare shows the selected C-F Ray and server headers. Google Tag Manager and Google Analytics show the H-T-M-L substrings that matched. Preserve those strings when sharing the result, because a technology name without its evidence is much harder to verify later.
Step 11
The separate tag inventory identifies supported loader or request evidence. In this fixture, Meta Pixel and Segment Analytics come from the local H-A-R. Google Tag Manager and two Google Analytics clues come from the page H-T-M-L, labelled D-O-M in the report. Duplicate identifier evidence means more than one clue points to the same supported identifier; it is useful for investigation, but it is not a duplicate-event verdict.
Step 12
Read the disclosure beneath the tag list. Loader or request evidence does not prove that a tag fired, transmitted data, or was accepted by its vendor. The local H-A-R parser also removes query values from retained evidence. To verify actual behavior, inspect the relevant network request, consent state, payload, response, vendor debugger, and destination data in an authorized test session.
Step 13
The methodology note keeps the result in bounds. A detection means a supported public signal matched. It does not mean the technology is definitely present, actively used, or used everywhere. Sites can remove, proxy, spoof, or change public signals. This is also not a security scan.
Step 14
For beginners, remember four rules. High confidence means multiple supported signatures. Medium means one. Evidence names the rules that fired and still needs review. No signatures matched means only that this raw H-T-M-L and the selected headers lacked a known signal. It is never proof that the technology is absent.
Step 15
The server fetches public raw H-T-M-L and a selected response-header map. In the browser, the detector lowercases those values and checks a curated JSON signature list covering H-T-M-L substrings, generator metadata, supported headers, and supported cookie names. Results are grouped by technology and sorted. Run the tool again when the page or signature data changes; the report is a point-in-time observation.
Step 16
The main features are broad public-fingerprint categories, exact evidence for every technology detection, transparent high and medium confidence levels, browser-side matching after the bounded public fetch, and optional local H-A-R tag evidence. The sample report, interpretation guide, privacy notes, and limitations stay on the same page so the output is easier to use responsibly.
Step 17
The checker does not render JavaScript, crawl a whole site, identify private infrastructure, verify software versions, test vulnerabilities, scan ports, authenticate into an application, or prove tag execution. Proxies, tag managers, cached markup, and removed or spoofed fingerprints can create false negatives or false positives. Treat every result as a lead supported by visible evidence, not as a complete stack or security assessment.
Step 18
Next, repeat the check on representative product, article, category, regional, and subdomain templates when they matter. Save the page U-R-L, date, technology, category, confidence, and exact evidence. Confirm important findings in source, selected response headers, rendered browser behavior, the platform, and vendor tools. If the decision involves versions, vulnerabilities, private infrastructure, or complete tag behavior, use a purpose-built authorized check.
Use the report as evidence for the next check—not as final proof.
The useful output is not just a technology name. It is the category, confidence, and exact public fingerprint that matched. Save that evidence, repeat the check on representative templates, and confirm important findings in source, response headers, rendered behavior, or the platform itself before making a migration, analytics, security, or implementation decision.
Common issues & how to fix them
- Information CMS fingerprint is publicly visible Fix: If CMS disclosure is unintended, remove generator metadata and public version markers while keeping required assets functional.
- Information Framework fingerprint is publicly visible Fix: If framework disclosure creates risk, suppress version-specific headers and signatures and keep the framework fully patched.
- Information Analytics or tag-manager fingerprint is visible Fix: Audit every detected analytics and tag-manager script, remove unused tags, and gate nonessential tracking behind consent where required.
- Warning Server technology is disclosed in headers Fix: Remove or generalize Server and X-Powered-By headers at the origin or proxy, and patch the disclosed software.
- Warning Technology fingerprints conflict Fix: Inspect the conflicting headers, markup, and assets, then remove stale signatures so the reported stack matches production.