This checker vs. manually checking against the guidelines yourself

Reading wordpress.org's Detailed Plugin Guidelines and re-checking your own readme.txt and PHP files against it by eye is the default first pass -- and every plugin author already does it. It reliably misses the two checks that require cross-referencing two separate files or scanning an entire file for the absence of something, which is exactly what this free tool automates.

What a manual guidelines read-through involves

wordpress.org publishes the Detailed Plugin Guidelines as prose -- readme.txt format, required and recommended header fields, security expectations, and more, laid out as paragraphs rather than a literal checklist. Preparing a submission means reading through that page, then re-reading your own readme.txt and every PHP file against it, holding each rule in mind as you go.

That works well for anything visible in one place: an obviously missing License line, a readme.txt that clearly does not follow the standard format. It works less well for a rule that spans two files that live nowhere near each other, or a rule that asks you to confirm an absence across every line of every file -- both are easy to satisfy in your head ("I checked the readme, I checked the header, both look fine") without ever performing the specific cross-check the rule actually requires.

The two checks a read-through is most likely to skip.
What the guidelines ask	Reading through by eye	This checker
readme.txt's `Stable tag` matches the plugin header's `Version`.	Requires opening two files and comparing two short strings against each other -- easy to skip when each file individually looks correctly formatted.	Reads both files and compares the two values automatically, every time.
Every `$_POST` handler is guarded by a nonce check somewhere in the same file.	Requires holding the question open while scanning every line of every file -- tedious in a small plugin, easy to lose track of in a large one.	Scans every file's `$_POST` usage against every known nonce-check function name.
Every superglobal value printed with `echo`/`print`/`printf` is escaped on the same line.	An escaping function a few lines away, or on a different variable on the same line, can look right at a glance.	Checks the exact line for both the output statement and an escaping call together.
Required readme.txt and header fields are all present.	A field that "looks like it's probably there" from memory of past submissions.	Checks each required field name explicitly and lists exactly which are missing.

Reading the guidelines is not wrong -- it is the only way to learn what a submission needs to look like at all, and this tool does not decide anything about your plugin the guidelines don't already say. What it automates is the narrow, mechanical cross-checking a careful read-through is most likely to let through under a deadline.

Run the free plugin review checker

The same 15-line example a guidelines read-through would pass

This is this tool's own bundled worked example -- short enough to read end to end in a few seconds:

=== Example Plugin ===
Stable tag: 1.2.0
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

<?php
/**
 * Plugin Name: Example Plugin
 * Version: 1.3.0
 */
if ( isset( $_GET['name'] ) ) {
    echo 'Hello, ' . $_GET['name'];
}
function example_save_settings() {
    if ( isset( $_POST['example_option'] ) ) {
        update_option( 'example_option', $_POST['example_option'] );
    }
}

Read start to finish, both files look ordinary: the readme has every required field, the plugin header has a name and a version, and the code is short enough that nothing about it looks alarming. Run this checker's own detection logic against it and it reports three separate issues: the readme's Stable tag: 1.2.0 does not match the header's Version: 1.3.0; the echo on line 11 prints $_GET['name'] with no escaping function; and example_save_settings() reads $_POST['example_option'] with no check_admin_referer, check_ajax_referer, or wp_verify_nonce call anywhere in the file. All required readme and header fields are present, so none of the three issues is a missing-field problem a quick skim would catch -- each one needs the specific cross-check above.

Common questions

Isn't reading the guidelines and checking my own code enough?

It is the step every plugin author already takes, and it works for anything you can see in one place -- a missing License field, an obviously unescaped block. It works less well for anything that requires cross-referencing two files that live far apart (readme.txt's Stable tag against the main plugin file's Version header) or holding one rule in your head while scanning every line of every file in the plugin (does every $_POST read have a nonce check somewhere in this file?). Neither task is hard once you know to do it -- they are just easy to skip while reading for the dozens of other things the guidelines also cover.

How easy is it really to miss a Stable tag mismatch by eye?

In a 15-line worked example built specifically to demonstrate this tool -- short enough to read in ten seconds -- the readme.txt says Stable tag: 1.2.0 and the plugin file's header comment says Version: 1.3.0, three lines apart in two different files. A guidelines read-through checks each file looks correctly formatted; it does not by default diff the two version strings against each other, because nothing about reading either file in isolation calls attention to the other one.

Why is a missing nonce check easy to miss in a manual read?

Because the guidelines ask you to confirm a negative across an unbounded search: does any $_POST handler, anywhere in this file, lack a nonce check anywhere else in the same file? In a plugin with a handful of files that is tedious but doable. In a plugin with dozens of files handling forms, AJAX actions, and admin-post hooks, holding that question open while reading line by line is exactly the kind of check a deadline compresses first -- and unlike a formatting typo, a missing nonce check produces no visual cue that draws the eye.

Does this tool replace reading the guidelines?

No, and it checks only four specific, common patterns out of everything the Detailed Plugin Guidelines cover. Reading the guidelines is still how you learn what a first submission needs to look like at all. This tool exists for the narrower, mechanical part of that job -- cross-referencing two files and scanning every line for one of four patterns -- which is exactly the part a careful, unaided read-through is most likely to let through.

Already run wordpress.org's own Plugin Check? See how it compares to this checker. More on the most common single issue: Fixing a readme.txt "Stable tag" mismatch.