Free Online WordPress Tools
WordPress tools for the two questions people ask about someone else’s site and the one they ask about their own: which theme is rendering this page, which plugins are loading on it, and does my plugin readme.txt say what the directory expects.
Showing 3 tools
WordPress Theme Detector
Find out which WordPress theme a site runs, with the version, the author, the parent theme and the evidence each answer came from.
WordPress Plugin Detector
See which WordPress plugins load on any page, with the folder slug, the version, the install count and the evidence each one came from.
WordPress Readme Generator
Write a plugin readme.txt the WordPress.org directory parses, with a live preview of the listing it produces and a download when it is right.
WordPress runs a large share of the web, and these tools answer the three questions that come up most often about it: what is this site running, what is loading on this page, and does my own plugin’s readme say what the directory expects. The first two read a site from the outside, using what WordPress publishes about itself in every page it serves. The third runs entirely in your browser and never touches a site at all.
Which one you want depends on whose site it is. Looking at someone else’s and wondering how the design was built, use the WordPress theme detector: it reads the theme name, version and author from the theme’s own style.css, works out whether it is a child theme and names the parent. Wondering what is doing the work rather than the styling, the plugin detector lists every plugin folder loading assets on the page, with real names and install counts where the catalogue knows them. Shipping a plugin of your own, the readme.txt generator builds the file WordPress.org parses, with a live preview of the listing it produces.
The two detectors share one scan and split the answer, because a theme question and a plugin question have different evidence and different limits. Both say which signal each answer came from, and both report what could not be checked rather than presenting a short list as a complete one - a managed host that blocks /wp-content/ can hide everything, and calling that "not WordPress" would be a confident wrong answer.
Which of the three answers your question
| If you are asking | Use | What you get back |
|---|---|---|
| What theme is this site using? | Theme detector | Theme name, version, author, and the parent of a child theme |
| Which plugins run on this page? | Plugin detector | Plugin folders with names, versions and install counts |
| Is my plugin readme.txt right? | Readme generator | A readme.txt the directory parses, plus a preview of the listing |
| Is this site even WordPress? | Either detector | A verdict that separates "no" from "could not check" |
How detection actually works
Nothing here guesses. WordPress serves its own structure in every page it renders: themes load stylesheets from /wp-content/themes/<slug>/, plugins load scripts and images from /wp-content/plugins/<slug>/, core assets come from /wp-includes/, the REST API is advertised in a link tag and a Link header, and many installs still emit a generator meta tag naming the version. Those paths are facts about the response, not inferences from how a page looks, which is why the report can list the literal evidence beside every answer.
A theme gets one more step. Once the folder is known, the scanner asks that folder for its own style.css and reads the header block WordPress requires: Theme Name, Version, Author and, on a child theme, the Template line naming the parent it extends. That is how a slug becomes a name and how a child is told apart from what it inherits from. The version in that header is the theme author’s number, so it is accurate on an untouched theme and unreliable on a patched one - the report says so rather than presenting it as installed truth.
Plugins get a catalogue lookup where one is available, which turns a folder slug into a published name, a current version and a rough install count. A premium plugin sold outside the WordPress.org directory has no entry to match, so it stays a folder name: still a real finding, and usually enough to identify the product.
What these tools cannot see, and why that matters
Every honest detector has a blind spot, and pretending otherwise is how a tool produces confident nonsense. A caching or optimisation plugin that concatenates every script into one combined file erases the plugin folder names inside it, including its own. A host that proxies assets through a CDN path can remove /wp-content/ from the page entirely. A plugin that only runs in wp-admin, or only fires on a checkout page, loads nothing on the page you scanned. In all of those cases the honest answer is "nothing was visible here", which is not the same as "nothing is installed".
That is why both detectors list what could not be checked above the results instead of leaving an empty section to be misread, and why scanning an interior page - a post, a product, a contact form - reliably returns more than a homepage does. If you are auditing a site properly, scan two or three pages and treat the union as the floor.
Publishing a plugin of your own
The readme.txt file is the whole public face of a plugin in the WordPress.org directory, and its format is fussy in ways that stay invisible until something breaks. Stable tag decides which version users actually receive, so a wrong one ships nothing however much you committed to trunk. Tested up to is what produces the "untested with your version of WordPress" warning on the listing. Tags index the first five and quietly ignore the rest. The short description is truncated at 150 characters in search results.
The generator states each of those limits at the field it belongs to and lists what the directory would do with your file before you download it. It also reads an existing readme back into the form, which is the fastest way to bring an old plugin’s file up to current requirements without retyping it.
Frequently asked questions
Are these WordPress tools free?
Yes, all of them are free and need no signup. The two detectors are rate-limited per visitor so one person cannot exhaust the service; the readme generator runs client-side and has no limit at all.
Why are the theme detector and the plugin detector separate tools?
They answer different questions from the same scan. A theme answer rests on a stylesheet path and a style.css header; a plugin answer rests on asset paths and a catalogue lookup, and comes with a much bigger caveat about what cannot be seen. Presented as one report the two halves competed, and the plugin list’s limits got read as the theme answer’s.
Can a tool see plugins that are installed but not active?
No. Detection works by what a page loads, so a deactivated plugin is invisible, and so is an active one that adds nothing to the front end of the page you scanned. The plugin list is a floor, not an inventory.
Do the detectors work on a site that is not WordPress?
They tell you it is not. The report separates three outcomes: WordPress with the answer found, WordPress where the answer could not be read, and no WordPress signals at all. A hidden /wp-content/ never becomes "not WordPress".
Does readme.txt hold my plugin’s banner and icon?
No. readme.txt is plain text. The banner and icon live in the plugin’s /assets/ folder in SVN as banner-1544x500.png and icon-256x256.png, and screenshots as screenshot-1.png upwards, matching the numbered captions in the readme.
Is anything I scan or write stored?
No. A scan is performed and returned to you without being written to a database, and the site you scanned sees one ordinary request in its logs. The readme generator keeps your draft in your own browser so a reload does not lose it, and nothing is uploaded.