An automation tool, a reporting service or a publishing app has asked you to “create an application password” in WordPress. Or you were tidying up your profile and found a section at the bottom called Application Passwords, possibly with entries in it you do not remember adding. Either way, it is worth knowing what these are before you create one or delete one.
WordPress application passwords let other software connect to your site on your behalf without ever knowing your real password. Each one can be cancelled in a click. They also bypass some of the protection on your normal login, which is the reason to understand them before you create one.
What application passwords are for
Your normal password is for you, typing into the login form. Some tools need to talk to your site without a person at the keyboard: an app that publishes posts from your phone, a service that copies form entries or orders into another system, an automation platform that creates draft posts, or a script your developer wrote. These connect through WordPress’s programming interfaces, mainly the REST API and the older XML-RPC.
Before application passwords existed, such tools often asked for your real password. That meant handing your main login to another company, and changing it broke everything at once. An application password solves both problems:
- Each tool gets its own password, so you can cancel one without affecting the others.
- Your real password is never shared, so you can change it freely.
- An application password cannot be used to log in to the dashboard. WordPress rejects it on the normal login form.
They have been part of WordPress itself since version 5.6, so you do not need a plugin.
How much power WordPress application passwords carry
An application password acts as the user who created it, with that user’s full role. If an administrator creates one, any tool holding it can do through the API almost anything that administrator could, including editing content and changing users. It does not get a smaller set of permissions just because it is a “separate” password.
So the question to ask is not only “do I trust this tool?” but “which account should this tool use?”. For many integrations the honest answer is a dedicated account with a limited role, rather than the owner’s administrator account. More on that below.
How to create an application password
- Log in and go to Users → Profile. An administrator can also open another user’s profile from Users → All Users.
- Scroll to the Application Passwords section near the bottom.
- In New Application Password Name, type a name that identifies the tool and the purpose, for example “Zapier – form entries to CRM” or “Phone app – Priya”. You will rely on this name later when deciding what to revoke.
- Click Add Application Password.
- WordPress shows the new password once, in groups of four characters. Copy it straight into the tool that needs it. The spaces are optional.
You cannot view the password again after leaving the screen. If you lose it, revoke that entry and create a new one; it takes seconds.
Some tools use a smoother route: they send you to an Authorize Application screen on your own site, which names the app and asks whether you approve the connection. Approving creates the application password and hands it to the tool automatically. Check that the address bar shows your real website before approving.
If you do not see the section
WordPress only offers application passwords on sites served over HTTPS, so a site without a working certificate will not show it. A security plugin may also have switched the feature off, since some include that option. And on some servers that already use a basic password prompt in front of the site, WordPress shows a message saying the two are not compatible.
Reading the list and revoking passwords
Each application password appears in a table with its name, when it was created, when it was last used and the last IP address that used it. That gives you a simple way to review them:
- Never used, created months ago: probably a test or an abandoned setup. Revoke it.
- Used recently by a tool you know: keep it.
- Used recently, but you cannot place the name: ask around before revoking, because something in your business may depend on it. If nobody can explain it, revoke it.
Click Revoke next to any single entry to cancel it at once. The tool using it will start failing on its next attempt, which is a quick way of finding out who relied on it. There is also a Revoke all application passwords button for clearing the lot.
When a person leaves, or a developer’s job ends, their application passwords should go too. Deleting the user removes them automatically; downgrading the user does not, so revoke them by hand. The steps for ending outside access are in the guide to giving a developer access to WordPress.
The risks, plainly
Application passwords are not dangerous in themselves, but they behave differently from normal logins in ways that matter for security.
- Two-factor login does not apply to them. They are built for software, so the second step you set up for your own login is skipped. A stolen application password works without your phone. Our guide to WordPress two-factor authentication mentions this for the same reason.
- They do not expire by themselves. One created years ago for a tool you cancelled still works until it is revoked.
- Changing your main password does not cancel them. If you think an account has been misused, revoke its application passwords as well as resetting the password.
- They carry the full power of the account. An application password on an administrator account is a key to the whole site.
During any security check, look at the Application Passwords section on every administrator’s profile. An entry nobody recognises, especially one used recently from an unfamiliar address, should be treated in the same way as an unknown admin account: record the details, revoke it, and find out how it got there.
A safer pattern for integrations
For a tool that only needs to create draft posts, there is no reason for it to act as the owner. Create a separate account for the integration, named after the tool, with the lowest role that lets it do the job, and create the application password on that account. If the tool only needs to publish posts, Author may do. If it needs something unusual, a custom user role can be built for it.
Anything the tool does is then clearly labelled in revisions and logs. If the service is ever compromised, the damage is limited to what that role can do. And when you stop using the tool, deleting one account removes everything it had.
Accounts and their access are covered more broadly in the hub on managing WordPress users, and the rest of the site in our guide to managing a WordPress website.
Frequently asked questions
Should I turn off application passwords if I do not use them?
It is a reasonable choice for a simple brochure site with no outside tools connected. Some security plugins offer it as a setting. Check first whether anything relies on them, such as a mobile publishing app, a backup or management service, or an integration your developer set up, because turning them off will break those connections.
Why does a tool say my application password is wrong?
Check the username first: the tool needs the username or email of the account that created the password, not your own if they differ. Then check for a stray character from copying. If both are right, the site may not be on HTTPS, or a security plugin or the server may be blocking the request.
What happens to an integration if I delete the user it connects through?
It stops working straight away, because the application passwords are deleted along with the account. Before deleting a user, check their profile for application passwords and move any tool you still need to another account, ideally one created just for that tool.
Is it safe to paste an application password into a third-party service?
That is what they are designed for, but only do it for services you trust and recognise. Give each service its own password with a clear name, and revoke it when you stop using the service. Never send one by email or chat to a person you have not verified.
If you find application passwords you cannot explain, or an integration has stopped connecting, our WordPress bug fixing service can trace what is using them and tell you what is safe to remove.
Next in this series: How to Create a Custom User Role in WordPress
