What this tool does
Logging into WordPress takes a username and a password, but the login page never directly reveals which usernames actually exist. This checker tests two separate mechanisms — neither originally designed as a security flaw — that can still leak that information anyway: author archives and the REST API.
The /?author=N redirect
Every WordPress user has a public archive page listing their posts, reachable at /?author=N, where N is their internal numeric ID. WordPress automatically redirects that URL to the archive's final address, which contains the username — for example /author/admin/. This feature exists for a legitimate editorial reason (letting readers browse an author's posts), but it doubles as a username-discovery tool for anyone systematically trying different IDs.
The REST API: faster, potentially more complete
The /wp-json/wp/v2/users endpoint, introduced with WordPress's REST API, can return the full list of public users in a single request — usernames and often full display names, with no need to guess IDs one at a time the way the archive method requires. It's the more efficient of the two techniques when it's available, and it's worth checking independently, since a site may have patched one leak without ever thinking about the other.
Why a username alone isn't enough for an attacker
Knowing a valid username doesn't grant account access — the matching password is still required, and WordPress normally rate-limits repeated login attempts. But this leak removes half the problem for an attacker: instead of guessing both a username and a password, they only need to focus on the password, which meaningfully cuts down the effort needed for a brute-force or dictionary attack.
An old vulnerability that's still everywhere
Both of these techniques have been documented for years and yet remain effective against a large share of default WordPress installs, precisely because they aren't bugs in the strict sense — they're features with an unintended side effect that nobody planned for at design time. A targeted fix (blocking the ?author=N redirect, restricting the REST users endpoint) is usually enough to close both leaks without touching anything else on the site.