An application password is a separate password that WordPress makes for one app, so the app can use your site through its API without ever knowing your real password. It has been part of WordPress since version 5.6, in December 2020, and it is how most tools connect to a site — PressHand included.
Four things to know before anything else:
- It works for the REST API and XML-RPC only. It cannot log anyone into wp-admin.
- It acts as the user it belongs to, with that user’s full role. WordPress itself has no read-only kind.
- It is shown once, stored only as a hash, and never expires until someone revokes it.
- It needs HTTPS, unless the site is set up as a local development copy.
How to create one
- In wp-admin, go to Users → Profile. If your role cannot list users, it is simply Profile in the menu. An administrator can also do this for someone else, under Users → All Users → Edit.
- Scroll down to Application Passwords.
- Type a name in New Application Password Name. Use the app’s name, so you know later which one to revoke.
- Press Add Application Password. Before WordPress 6.8 the button said “Add New Application Password”, and many guides still use the old label.
- Copy the password straight away, with the Copy button. WordPress shows it once and keeps only a hash, so nobody can show it to you again — not even an administrator.
It looks like this: six groups of four letters and numbers, such as abcd EFGH 1234 ijkl MNOP 6789. That is 24 characters, with no symbols. The spaces do not matter: WordPress ignores them, so paste it with or without.
Which account? The password belongs to the account you are logged in as, and it can do everything that account can. For an app that only writes posts, create it from an Editor or Author account rather than your administrator.
How apps ask for one, without you copying anything
Good apps do not ask you to paste a password at all. They send you to a page on your own site, /wp-admin/authorize-application.php, which asks whether you would like to give the application access to your account. It shows the name the app gave itself and, under the buttons, exactly where you will be sent next.
Press Yes, I approve of this connection and WordPress creates the password and hands it straight back to the app. Press No, I do not approve of this connection and nothing changes.
Read that screen before you approve. The danger with application passwords is not someone guessing one — 24 random characters is far beyond that — it is being talked into approving an app you should not trust. The name on the screen is whatever the app chose to call itself.
PressHand uses this screen. You type your site address, approve it on your own site, and the key goes straight to the app on your computer; your WordPress password is never typed into it. One catch applies to every desktop app that does this, PressHand among them: WordPress accepts a return address on your own computer (http://127.0.0.1) only from version 7.0. On older versions, the approval screen stops with “The URL must be served over a secure connection.” Updating WordPress fixes it.
How to use one
Apps send it with your username — or your email address — using HTTP Basic authentication. To test one from a terminal:
curl --user "your-username:abcd EFGH 1234 ijkl MNOP 6789" https://example.com/wp-json/wp/v2/users/meIf that returns your user details, the password works. Use the exact https:// address from Settings → General. If the request is redirected on the way — from http to https, or to or from www — the password is dropped, and WordPress answers as though you had not logged in.
Administrators can also manage them with WP-CLI:
wp user application-password create alice "My app" --porcelain
wp user application-password list alice --fields=uuid,name,last_used
wp user application-password delete alice --allHow to revoke one
Back in Users → Profile → Application Passwords, each password has a row showing when it was created, when it was last used and the last IP address that used it. Press Revoke on one row, or Revoke all application passwords under the table. It stops working on the very next request. “Last used” is only recorded once a day, so treat it as approximate.
Two things catch people out. Changing your WordPress password does not revoke application passwords: only revoking them does, or deleting the user. And since WordPress 6.7 two passwords can share a name, so reconnecting an app can leave the old one working. Revoke the old row.
Why the Application Passwords section is missing
If the section is not on your profile at all, or an app’s approval page refuses, it is almost always one of these.
The site is not on HTTPS
WordPress only offers application passwords over HTTPS, and the profile screen says “The application password feature requires HTTPS, which is not enabled on this site.” Get a certificate — most hosts include one free — and make sure both addresses in Settings → General start with https. Behind a proxy or load balancer, WordPress can miss the HTTPS even when your browser shows it; the fix goes in wp-config.php, and your host will know the line.
On a development copy on your own computer, set WP_ENVIRONMENT_TYPE to local in wp-config.php. It has to be local: development does not work, whatever the profile screen suggests.
A security plugin switched them off
Wordfence turns application passwords off by default. The setting is “Disable WordPress application passwords”, under Wordfence → Firewall → All Firewall Options → Brute Force Protection; untick it. All-In-One Security has an optional “Disable application password” under User Security → Additional settings, Hostinger Tools has a “Disable application passwords” switch in its security settings, and the small Disable Application Passwords plugin does exactly what its name says.
Kadence Security, formerly Solid Security and iThemes Security, can limit them to some user groups when its two-factor module is on, and can mark a password Read Only — after which every change made through it fails.
The site is behind a password prompt
If the whole site sits behind HTTP Basic authentication — a password-protected staging site, or a host’s password protection — WordPress hides application passwords, because both need the same Authorization header.
They are switched off for your account
A site can turn them off for some users only. The message then says they are not available for your account; ask the site’s administrator.
Why requests fail with a 401
The error code in the response says where to look:
| Error | What it means | What to do |
|---|---|---|
incorrect_password | WordPress saw the credentials, and the password is wrong or revoked | Check you used the application password, not your login password; or create a new one |
rest_not_logged_in | WordPress never received usable credentials | Check HTTPS, redirects, security plugins and the Authorization header, below |
rest_cannot_create with a 403 | You are logged in, but the account’s role cannot do this | Use an account with the right role; a new password will not help |
On Apache hosts, the usual cause of rest_not_logged_in is the server stripping the Authorization header before WordPress sees it. WordPress’s own rule for this has been in its default .htaccess since 5.6. If yours is missing it, saving Settings → Permalinks writes it again (unless permalinks are set to Plain, or the file is not writable), or you can add it by hand inside the WordPress block, straight after RewriteEngine On:
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]Tools → Site Health checks this for you: if the header is not getting through, it says “The authorization header is missing”. And beware an older snippet that wraps the fix in <IfModule mod_setenvif>: Apache does not recognise that module name, so it quietly skips the line.
Keeping them safe
- One password per app, named after the app, so you can revoke one without breaking the others.
- The lowest role that does the job. An application password can do everything its account can.
- Revoke what you no longer use, and glance at “Last used” now and then.
- Read the approval screen: the app’s name, and where it will send you.
- Remember that they skip two-factor authentication, by design. Each one is a single key; look after it like one.
- Remove the old Application Passwords plugin if a site still has it. WordPress has had the feature built in since 5.6, and the plugin was closed in December 2025 with an unfixed security flaw.
On WordPress.com
Sites on a WordPress.com plan that allows plugins — Personal, Premium, Business or Commerce — have the same Users → Profile → Application Passwords section. WordPress.com accounts also have a separate kind, in the account’s two-step authentication settings, for apps that log in to the account itself. Those are 16 characters long, not 24.
If you are connecting an assistant such as Claude, our guide to Claude for WordPress compares the ways to do it, and the MCP Adapter guide shows where an application password fits in.
Questions people ask
Where do I find application passwords in WordPress?
In wp-admin, under Users → Profile, in the Application Passwords section near the bottom. If it is missing, the site is not on HTTPS, or a security plugin such as Wordfence has switched the feature off.
Can I see an application password again?
No. WordPress shows it once and stores only a hash. If you lose it, revoke it and create a new one.
Does changing my WordPress password revoke application passwords?
No. They keep working until you revoke them, one at a time or with Revoke all application passwords, or until the user is deleted.
Can an application password log in to wp-admin?
No. It only works for the REST API and XML-RPC, so it cannot be used on the WordPress login screen.
Do the spaces in an application password matter?
No. WordPress ignores everything except letters and numbers, so the password works with or without its spaces.
Why does Wordfence hide application passwords?
Wordfence switches the feature off by default. Untick Disable WordPress application passwords under Wordfence → Firewall → All Firewall Options → Brute Force Protection.