How to Find Out What WordPress Theme a Website is Using

You spotted a WordPress site with a layout you love — the typography, the spacing, the way the header collapses on mobile — and now you want to know exactly which theme is powering it. The good news: WordPress leaks this information almost everywhere, and you rarely need anything more than your browser's View Source. The better news: once you understand why the theme name is sitting in plain sight, you can identify it on most sites in under thirty seconds, and you'll know exactly what to do on the stubborn minority that hide it.

Why WordPress can't really keep its theme a secret

Every standard WordPress theme lives in a folder at /wp-content/themes/<theme-slug>/. When a page loads, WordPress enqueues that theme's stylesheet and scripts, and the full path to those files ends up hard-coded in the HTML the browser receives. So the theme's folder name — which is almost always the theme name in lowercase with hyphens — is printed directly into the page source. That's the single most reliable detection method, and it works without any tool, extension, or third-party service.

Method 1: Read the page source (the one that always works)

Open the site, then view the raw HTML — Ctrl+U (Windows) or Cmd+Option+U (Mac) in Chrome and Firefox. Use your browser's find (Ctrl/Cmd+F) and search for wp-content/themes. You'll typically land on a line like:

• <link rel="stylesheet" href="https://example.com/wp-content/themes/astra/style.css?ver=4.6">

The slug between themes/ and the next slash — astra in this case — is the theme. You'll often see the same slug repeated in <script src> tags and in inline asset paths. Search a few times: if you see two different theme slugs, one is almost certainly a child theme and the other its parent, which is extremely common and a useful clue in itself.

Why the slug isn't always the marketing name

Folder slugs are lowercase and often abbreviated. twentytwentyfour is the default "Twenty Twenty-Four" theme; generatepress is GeneratePress; kadence is Kadence. If the slug looks cryptic, don't guess — move to Method 2 and read the theme's own header, which states its real name.

Method 2: Open style.css and read the header block

Once you have the slug, go straight to the source of truth. Navigate to:

• https://example.com/wp-content/themes/astra/style.css

At the very top of that file is a comment block that WordPress itself parses to populate the Appearance screen. It looks like this:

• Theme Name: Astra
• Theme URI: https://wpastra.com/
• Author: Brainstorm Force
• Version: 4.6.1
• Template: astra (this line only appears on child themes — it names the parent)

This is the definitive answer. The Template: field is gold: if it's present, you're looking at a child theme, and the value tells you the parent you should actually go download. Some themes also ship a readme.txt in the same folder with licensing and version notes worth a glance.

Method 3: Detector tools and browser extensions

When you want speed or you're checking many sites, a detector does the page-source parsing for you and frequently identifies the plugins and hosting stack too:

• Wappalyzer — a browser extension and web app that reads the page and reports CMS, theme, plugins, analytics, and CDN. The most reliable general-purpose option.
• WPThemeDetector (whatwpthemeisthat.com) — paste a URL and it returns the active theme plus detected plugins.
• IsItWP and Scan WP — quick URL-in, theme-out checkers that also flag the host.
• BuiltWith — broader technology-profiling, useful when you want the full stack rather than just the theme.

Treat these as conveniences, not oracles. They parse the same signals you can read by hand, so when they fail, they fail for the reasons below — and the manual method will usually still get you an answer.

Method 4: Spotting block (full-site-editing) themes

Block themes — the default twentytwentyfour / twentytwentyfive line, plus Frost, Ollie, and Kadence's FSE builds — behave a little differently. They still live in /wp-content/themes/, so Methods 1 and 2 apply, but you'll also see a theme.json file in the theme folder and far less traditional per-page CSS, because much of the styling is generated and inlined from that JSON. If you load /wp-content/themes/<slug>/theme.json and get a real file rather than a 404, you're almost certainly looking at a block theme.

When detection fails — and what the tells actually mean

A meaningful minority of sites won't hand you a clean answer. Here's how to read each situation instead of assuming the tool is broken.

Custom and bespoke themes

If the slug is something like acme-custom or client-2025 and no detector recognizes it, that's because it isn't a public product — it was built for that site. There's nothing to download. The slug, the author line in style.css, and the markup conventions are your only clues to who built it.

Page builders wearing a generic shell

A site built almost entirely in Elementor, Bricks, or Divi often runs on a deliberately minimal theme — hello-elementor is the classic giveaway. The "design" you admire is the builder's output, not the theme. Identifying the builder (Wappalyzer flags these) matters more than the theme name in that case.

White-labeled and renamed folders

Agencies sometimes rename a theme folder or strip the style.css header to obscure a commercial theme they've resold. A renamed folder breaks the slug clue, but markup fingerprints, distinctive class names, and JavaScript bundle names often still betray the original.

Security plugins and aggressive caching

Plugins like the path-hiding features in some security suites can rewrite or mask /wp-content/ URLs. More commonly, full-page caching (WP Rocket, host-level caching) plus a CDN such as Cloudflare can rewrite asset paths or serve heavily optimized HTML where the original theme path is concatenated into a combined stylesheet. When the path is genuinely gone, fall back to detectors that fingerprint markup patterns, or check whether the site exposes the REST API at /wp-json/ — its presence at least confirms WordPress, even when the theme is buried.

A quick, repeatable workflow

1. View source, search wp-content/themes, grab the slug.
2. Open /wp-content/themes/<slug>/style.css and read the header for the real name, author, version, and any Template: parent.
3. If the slug is missing or cryptic, run the URL through Wappalyzer to catch the theme, the builder, and the plugins at once.
4. If everything's masked, identify the page builder and confirm WordPress via /wp-json/ — then accept that a bespoke or white-labeled build may have no off-the-shelf equivalent to buy.

Ninety percent of the time, the first two steps end the investigation in under a minute. The remaining cases aren't failures of method — they're information in themselves, telling you the design is custom, builder-driven, or deliberately hidden. Either way, you now know which it is.