Reading WordPress style.css Headers

A WordPress theme's style.css header is the structured comment block at the top of the file that names the theme, lists its author, and declares which theme it inherits from if it's a child theme. WordPress reads this block during theme installation and again on every page load.

The format is rigidly specified. WordPress parses it with a regex that expects exact field names followed by a colon and value, one field per line, inside a CSS comment block that starts with /* and ends with */. Anything outside the recognized fields is ignored. Anything missing from the required fields makes WordPress refuse to install the theme.

Required fields

Only two fields are technically required: Theme Name and (since WordPress 3.0) Author URI. Themes missing these won't appear in the Appearance → Themes admin screen. Everything else is recommended.

The full canonical field list, in the order WordPress.org's theme review team expects:

• Theme Name: the human-readable name shown in the admin. Required.
• Theme URI: public URL where the theme is hosted (typically the WordPress.org listing or the vendor's product page).
• Author: author name as a string. Free text.
• Author URI: author's website. Required.
• Description: one-paragraph description displayed under the theme name in the admin.
• Version: semantic version (e.g., 3.1.4). WordPress compares this against the version on WordPress.org to determine if updates are available.
• Tested up to: highest WordPress version the theme has been tested with. Helps the admin warn users running newer WordPress.
• Requires PHP: minimum PHP version. WordPress refuses to activate themes that need a higher PHP than the server runs.
• License: license name (typically "GPLv2 or later" for themes distributed on WordPress.org).
• License URI: link to the full license text.
• Text Domain: i18n text domain for translation files. Must be unique and typically matches the theme's directory name.
• Tags: comma-separated tags from WordPress.org's controlled vocabulary (e.g., "two-columns, responsive-layout, custom-colors").

Two more fields apply only to child themes:

• Template: the directory name of the parent theme. WordPress uses this to load the parent's template files when the child theme doesn't provide its own.

Why the header matters for detection

When you're identifying a WordPress theme from the public-facing site, fetching /wp-content/themes/{theme-name}/style.css and reading the header is the most authoritative source of truth. The directory name might be different from the display name. Custom-modified themes still preserve the original header. White-labeled themes (themes a shop has rebranded) sometimes change the Theme Name field but leave the Author URI pointing at the original developer.

Of the themes I've inspected via the style.css header, Astra is the one with the most consistent header data across installations because the theme is so widely-used that few people bother to rebrand it. GeneratePress and Kadence are similar. Divi and Avada more often have modified headers because agencies that resell those themes routinely white-label them for client deliveries.

Limitations of the header method

The header tells you what the theme developer wrote. It doesn't tell you what the site owner did to it. A theme can have any amount of custom CSS, custom template files, custom JavaScript, and custom functions added by a developer without changing the header at all. The header identifies the starting point, not the current state.

Themes built from "starter" frameworks (Underscores, Sage, Bedrock) inherit a generic header from the starter that doesn't change as the theme gets built out. A site running a fully custom theme built on Underscores still shows Theme Name: _s in its style.css until the developer manually updates the header. This is one reason agency-built sites often show generic starter theme names in detection: nobody changed the field.

The WordPress.org theme directory doesn't publish theme.json for themes that fork or substantially modify other themes, so reverse-tracing a heavily customized site back to its origin is a process of reading the actual code rather than trusting the header.

How this compares to detecting Shopify or Magento themes

Shopify and Magento use entirely different conventions. Shopify themes don't have an equivalent of style.css; the theme name is exposed through a JavaScript object called BOOMR that every Shopify store ships with for performance monitoring. Magento themes are namespaced by vendor (Vendor_ThemeName) and the namespace is visible in asset paths like /static/version*/frontend/Vendor/Theme/. WordPress's style.css convention is older, simpler, and more uniform than either of those approaches.