ThemeSniffer is a small independent project built around one question: what is this website made of? It answers that with a free Chrome extension and a set of free web tools, and it tries to be honest about the difference between what it knows and what it is guessing.
Who builds it
The extension and the tools are built and maintained by Ruslan Saifullin, a developer with over 10 years of WordPress experience across 20+ projects.
It started as a personal tool. Identifying the theme and plugins behind a site I admired meant opening DevTools, digging through source, and recognising patterns I had learned the slow way. That is a fine skill to have and a poor way to spend an afternoon, so it got automated — first for me, then for anyone.
You can follow the work on X at @ruslan_dev_ai, which is also the best way to get in touch.
What's here
Everything on this site is free to use, with no account required:
- The Chrome extension — detects the theme and plugins on whatever site you are looking at, from the toolbar.
- Tech Stack Report — theme, plugins, hosting, CDN and speed for any URL.
- Font Detector — every font family, weight and source a site loads.
- Color Palette Extractor — a site's colors with their roles, contrast, and copy-ready exports.
- Is It WordPress? — a quick verdict with a confidence level.
- The blog — guides on identifying themes, finding plugins, and researching what competitors are running.
How the detection works
There is no magic and no database of scraped sites. When you paste a URL, our server requests that page the same way your browser would, then reads what any visitor could read: the public HTML, and the stylesheets the page links to.
From that we look for signals that identify software — /wp-content/ paths, generator meta tags, theme stylesheet headers, plugin asset paths, response headers that name a host or CDN, @font-face rules, CSS custom properties like --wp--preset--color--primary that a theme's theme.json generates. Each signal is matched against patterns we maintain by hand.
Nothing you check is stored. The analysis happens per request and the result goes to your browser.
Why the reports admit what they missed
Every tool here reads a site from the outside, which sets a hard ceiling on what it can know. A server-side fetch cannot see anything JavaScript paints after load, anything drawn inside an image or canvas, or the computed result of the CSS cascade. On a stylesheet-heavy site we fetch a capped number of stylesheets rather than all of them, so results cover the highest-priority CSS.
Rather than quietly presenting a partial answer as a complete one, each report says what it covered: how many stylesheets were read, which signals fired, and where a result is inferred rather than declared. A confidence level is not decoration — it is the difference between "this site says it runs WordPress" and "this site looks like it does".
That honesty is the whole product. A detection tool that is confidently wrong is worse than no tool, because you act on it.
Corrections
Detection patterns go stale. Themes get renamed, plugins change their asset paths, hosts change their headers. If a tool here misidentifies something you know the answer to, that is a bug worth reporting — tell me on X and include the URL, and I would rather fix the pattern than have it be wrong for everyone else too.
Privacy in one line
The site uses Google Analytics for anonymous usage statistics, and the tools do not retain the URLs you analyze. The full details are in the Privacy Policy and the Terms of Service.