WordPress application passwords are revocable credentials, one per app, that let a tool sign in to your site's REST API or XML-RPC without knowing your real login password. They cannot log anyone into wp-admin, but they carry every permission of the user they belong to. The password itself is not the main security decision. The account you attach it to is.
TL;DR:
- Application passwords have been in WordPress core since version 5.6. They work only for REST API and XML-RPC requests, never for the wp-admin login screen.
- Each one is 24 characters long and is shown exactly once. If you lose it, revoke it and make a new one.
- An application password has all the capabilities of its user, with no read-only option in core, so attach it to the lowest-privilege account that can do the job.
- A missing Application Passwords section usually means the site isn't on HTTPS, or a plugin or host has switched the feature off.
- When a connection fails, read the error code.
incorrect_passwordmeans WordPress saw your credentials and rejected them.rest_not_logged_inmeans the credentials never arrived.
Table of Contents
- How Application Passwords Work, and What They Can't Do
- Creating an Application Password in Under a Minute (and Why You Only Get One Look)
- Permissions: The Password Inherits Everything, So Choose the User Carefully
- Why the Application Passwords Section Is Missing From Your Profile
- Connection Troubleshooting: Read the Error Before Changing Anything
- Revoking, Rotating and Auditing Access Across Several Sites
- Connect Claude or ChatGPT to Every Site You Run, One Application Password Each
- Frequently Asked Questions
- Sources
How Application Passwords Work, and What They Can't Do
Before WordPress 5.6, connecting an outside tool to your site meant installing an authentication plugin or handing over your actual login password. Neither was great. Application passwords fixed this by giving each tool its own credential. You can name it, track it and revoke it without touching your main login.
The mechanics are simple. A tool sends your username and the application password with each request using HTTP Basic authentication, the scheme defined in IETF RFC 7617. The credentials travel Base64-encoded in the Authorization header. Base64 is encoding, not encryption, so anyone who intercepts the request can read them. That is why WordPress insists on HTTPS before it will offer the feature.
The WordPress REST API handbook's authentication guide describes application passwords as the built-in way to authenticate requests from outside WordPress. Core checks for them only on API requests, meaning REST and XML-RPC. Type one into the normal login form and it fails. That is deliberate: a leaked application password gives someone API access, not a dashboard session.
Here is how the two kinds of credential compare:
| Your login password | An application password | |
|---|---|---|
| Works on wp-admin login screen | Yes | No |
| Works for REST API / XML-RPC | Not in core | Yes |
| Can you see it again later? | You chose it | No, shown once |
| Revocable without changing your login | No | Yes, individually or all at once |
| Covered by a two-factor prompt | Usually, if you've set one up | No, by design |
| Permissions | Everything your role allows | Everything your role allows |
The last row is the one people overlook. The table makes application passwords look like a safer, cut-down credential, and in most ways they are. In what they can actually do, they are identical to your login.
Creating an Application Password in Under a Minute (and Why You Only Get One Look)
You create one from the profile screen of the user the tool will act as.
- Go to Users → Profile (or edit another user, if you're an administrator).
- Scroll to the Application Passwords section near the bottom.
- Type a name that tells future-you what it's for, such as "AI client – office Mac – 2025".
- Click "Add New Application Password."
- Copy the password immediately. WordPress shows 24 characters in six groups of four, separated by spaces.
24 characters, shown once. WordPress stores only a hash of an application password, so not even an administrator can retrieve it later.
The spaces are for readability. WordPress strips them before checking the password, so you can paste it with or without them. If a tool refuses to accept spaces, remove them and it will still work.
If you miss the copy step, don't go hunting for the password. Revoke that entry and create another. It takes ten seconds, and a password sitting half-remembered in a notes app is worse than a fresh one.
Developers building an integration can skip the copy-and-paste step entirely. The Application Passwords integration guide on Make WordPress Core documents an authorization flow at /wp-admin/authorize-application.php. Your app sends the user there with an app name and a success URL. The user approves the request while logged in, and WordPress passes the new credential back to your app.
Permissions: The Password Inherits Everything, So Choose the User Carefully
There is no "read-only application password" in WordPress core. The credential acts with the full capabilities of its user. An application password on an Administrator account can install plugins, delete users and edit theme files. One on an Author account can publish that author's posts and nothing more.
There is no scoped or read-only application password in core. The account's role is the only permission boundary you get.
This makes the user you choose the real security decision. The OWASP REST Security Cheat Sheet recommends giving API clients only the access they need. In WordPress terms, that means matching the role to the job:
- Editor for content work. An Editor can write, edit and publish any post or page, manage categories and moderate comments. It can't install plugins or change settings. For a tool that only drafts and tidies content, this is the role I'd pick.
- Administrator only when the job demands it. Plugin updates, menu and theme changes, and site settings need Administrator capabilities. If the tool does those jobs, give it admin access knowingly, and accept that the password is now as powerful as your own login.
- A dedicated user, not your personal account. Create a user called something like "automation" and attach the password there. Its edits show up under that name in revision history, and you can delete the whole account in one move if you ever need to cut it off.
My position: use a dedicated Editor account by default, and upgrade it to Administrator only on sites where you actually want the tool touching plugins. Convenience is not a good enough reason to make every connection an admin connection.
Why the Application Passwords Section Is Missing From Your Profile
You scroll to the bottom of the profile screen and the section isn't there. There are three usual causes.
The site isn't served over HTTPS
WordPress makes application passwords available only when the site uses SSL. The one exception is an environment type set to local, so you can test on your laptop without a certificate. If your site still loads over plain http://, fix that first. It's long overdue anyway.
A plugin has turned the feature off
WordPress provides a filter, wp_is_application_passwords_available, that any plugin can use to switch the feature off. Some security and hardening plugins do exactly this, often behind a checkbox labeled something like "disable application passwords." Check your security plugin's settings before you assume anything is broken.
Your host or a custom snippet disabled it
Some managed hosts disable the feature at the platform level. A previous developer may also have left a add_filter( 'wp_is_application_passwords_available', '__return_false' ); line in functions.php or an mu-plugin. Search your codebase for the filter name. It takes thirty seconds and often settles the question.
Connection Troubleshooting: Read the Error Before Changing Anything
When a tool won't connect, most people regenerate the password and try again. That fixes the problem maybe a third of the time. A better approach is to look at the JSON error WordPress sends back, because it tells you which part of the chain failed.
| Error or symptom | What it means | Where to look |
|---|---|---|
incorrect_password (401) |
WordPress received your credentials and rejected the password | Typo, revoked password, or you used your login password instead |
invalid_username (401) |
The username doesn't match any user | Use the login username, not the display name |
rest_not_logged_in (401) on an endpoint that needs auth |
The credentials never reached WordPress | Server stripping the Authorization header |
application_passwords_disabled |
The feature is switched off site-wide | Security plugin, host setting, or a filter |
rest_cannot_create / rest_forbidden (401/403) |
You're authenticated, but the user lacks the capability | The user's role is too low for this action |
| HTML error page or 403 with no JSON | Something blocked the request before WordPress loaded | Firewall, WAF rule, or host-level REST API block |
The most common hidden culprit is the third row. On some Apache setups, particularly those running PHP as CGI or FastCGI, the server drops the Authorization header before PHP ever sees it. The MDN reference for the Authorization header explains what the header carries. When it's missing, WordPress treats the request as anonymous. The usual fix is to make sure this line sits in your .htaccess, inside the WordPress rewrite block:
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
Recent versions of WordPress write this line into the default rules. Sites with heavily customized or very old .htaccess files often don't have it.
Pro Tip: Test against /wp-json/wp/v2/users/me with curl before blaming the tool: curl --user "automation:abcd efgh ijkl mnop qrst uvwx" https://example.com/wp-json/wp/v2/users/me. If you get your user back, authentication works and the problem is in the tool's configuration. If you get incorrect_password, the header arrived and the credential is wrong. If you get rest_not_logged_in, the header was stripped somewhere between the internet and PHP, so stop regenerating passwords and go look at the server.
Revoking, Rotating and Auditing Access Across Several Sites
Each entry in the Application Passwords list shows when it was created, when it was last used, and the IP address it was last used from. That last column is quietly useful. If a password named "office Mac" was last used from an IP on another continent, you have your answer about whether to revoke it.
A sensible routine for anyone running more than a couple of sites:
- One password per tool, per machine. If your laptop is stolen, you revoke the laptop's entries and leave the server's alone.
- Name with a date. "AI client – laptop – 2025-03" makes stale entries obvious at a glance.
- Prune quarterly. Anything not used in 90 days is a credential with no job. Revoke it.
- Revoke everything when someone leaves. The "Revoke All Application Passwords" button on that user's profile is faster than tracking down which tools they connected.
Rotation is cheap because nothing else depends on an application password. Changing one never logs you out of the dashboard, and it never breaks the other tools connected to the same account.
Connect Claude or ChatGPT to Every Site You Run, One Application Password Each
Everything above, from the dedicated user and the right role to the header that has to survive the trip, is the setup PressHand relies on. It runs on your own machine or server, connects to each WordPress site through a standard application password, and lets Claude or ChatGPT handle 83 admin jobs in plain English. Those jobs include writing posts and pages, sorting images and menus, updating plugins, moderating comments, and scoring live pages for SEO out of 100 alongside Yoast, Rank Math, All in One SEO or SEOPress.
The license is $97 once, for every site you own, with no per-site fees. The Agency license is $197 and adds rebrand and resell rights. Updates are optional at $49 a year after the first 12 months. The honest limit: PressHand can only do what the connected user's role allows. Attach an Editor password and plugin jobs will fail, as they should. And if your server strips the Authorization header, nothing connects until you fix that first.
Frequently Asked Questions
Can I use an application password to log in to wp-admin?
No. WordPress accepts application passwords only on REST API and XML-RPC requests, so the normal login form rejects them. This is deliberate, so that a leaked application password can't be used to open a dashboard session.
Why don't I see the Application Passwords section on my profile?
The most common reason is that the site isn't served over HTTPS, which WordPress requires except on environments marked as local. A security plugin, a hosting setting or a custom filter can also disable the feature. Check your security plugin's settings and search your code for wp_is_application_passwords_available.
Are WordPress application passwords safe?
They are safer than sharing your login password, because each one can be revoked on its own and is stored only as a hash. However, they carry every capability of their user and aren't covered by two-factor prompts. Attach them to a dedicated, lowest-privilege account and always use HTTPS.
What's the difference between the incorrect_password and rest_not_logged_in errors?
incorrect_password means WordPress received your credentials and the password didn't match. rest_not_logged_in on an authenticated endpoint usually means the Authorization header never reached WordPress, often because the server stripped it. The fix for the first is a new password, and the fix for the second is a server configuration change.
Do the spaces in an application password matter?
No. WordPress displays the 24 characters in groups of four for readability and strips the spaces before checking the password. You can paste it with or without them.
Can I make a read-only application password?
Not in WordPress core. An application password always has the full capabilities of its user. To limit what a tool can do, attach the password to a user with a lower role, such as Editor or Author.