Detect technologies used by a website: frameworks, CMS, analytics, CDN, hosting, and server software from client-side signals.
Paste a page's HTML source, or point this tool at a URL, and it scans the markup - meta tags, script and link paths, inline JS globals, cookie names - and any response headers it can read, matching them against a reference list of known technology fingerprints for CMS, JS frameworks, analytics, CDN, and hosting. Most people expect it to profile any site from a URL alone; in practice a live cross-origin fetch is limited by the browser's CORS rules, so header-based signals like Server or X-Powered-By are frequently unavailable, and pasting the full page source gives noticeably more complete results.
A concrete input and expected output from the current implementation.
Input
<meta name="generator" content="WordPress 6.5.2" /> <link rel="https://api.w.org/" href="https://example.com/wp-json/" /> <script src="https://example.com/wp-content/themes/twentytwentyfour/js/script.js"></script> <script async src="https://www.googletagmanager.com/gtag/js?id=G-ABC123"></script>
Expected output
CMS: WordPress 6.5.2 (meta generator tag) Theme: twentytwentyfour (wp-content/themes path) REST API: WordPress REST API exposed (wp-json link) Analytics: Google Analytics 4 (gtag.js, ID G-ABC123) Server / CDN / Hosting: not detected
Each line comes from one distinct string in the pasted markup; no HTTP headers were included in this input, so the server, CDN, and hosting fields have nothing to match against and stay empty.
The tool searches the supplied HTML for known fingerprint strings - meta generator tags, characteristic script or stylesheet paths (wp-content, cdn.shopify.com, __NEXT_DATA__), inline JS globals, and cookie names - and reports a match wherever one of these signatures appears verbatim, along with the snippet that triggered it.
If you give it a URL instead of pasted source, it runs a browser fetch to retrieve the page, which is subject to the same-origin policy: unless the target server sends permissive CORS headers, the browser withholds most response headers and may block the body entirely, so server- and CDN-identifying headers are often missing for third-party domains.
Because the browser enforces CORS on cross-origin fetches. Unless the target site opts in with permissive Access-Control-Allow-Origin headers, the tool can't read most response headers and may not get the body at all, so header-based clues like Server or CDN headers are often missing when you supply just a URL.
Only if the Server header is present in a response the browser actually let it read, which requires either a same-origin fetch or a CORS-permissive target. Many hosts and CDNs strip or generalize this header for security, so it's frequently unavailable even when everything else works.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.