What is a WordPress application password and is it safe to give one to a developer?

What an application password is

Application passwords have been built into WordPress since version 5.6, so no plugin is needed. They exist so that outside software, such as a mobile app, an automation service or a developer’s maintenance tools, can connect to your site without knowing your real password.

• Each one is tied to a single user account and has a name you choose, such as the name of the company using it.
• WordPress shows the password once, at the moment it is created. After that only a scrambled version is stored, so nobody can look it up later, including you.
• You can create as many as you need, one per app or person, and remove each one separately.
• The list shows when each password was last used and the IP address, the network address of the computer that used it.

What it can and cannot do

An application password is accepted by the REST API, and by the older XML-RPC interface where that is still enabled. It is refused on the normal login page, so nobody holding one can sign in to your dashboard, open your profile or change your real password or email address through it. Your two-factor login is unaffected.

Within the REST API, it can do whatever the user who created it is allowed to do. WordPress does not currently let you limit one to reading only, or to certain parts of the site. For an administrator that includes creating and editing pages and posts, managing users, and installing or deactivating plugins. For that reason, only give one to a person or service you would be willing to have as an administrator, and revoke it when the work is done.

WordPress only offers application passwords on sites that use https. Some security plugins switch the feature off, so if the section is missing from your profile, look in your security plugin’s settings for an option about application passwords.

How to create one under Users, then Profile

1. Log in to your WordPress dashboard and go to Users, then Profile.
2. Scroll down to the section headed Application Passwords.
3. Type a name in the New Application Password Name box that says who it is for, for example the developer’s company name.
4. Click Add New Application Password.
5. WordPress displays the new password once. Copy it, pass it on through a secure channel, and then leave the page.

Avoid sending an application password in an ordinary email. Where the service offers the authorise application screen described below, use that, because the password then goes straight to the application and nobody has to copy or send it.

The authorise application screen

WordPress has a built in approval page so that you never need to handle the password yourself. The developer or service sends you a link to your own website. You log in as normal, on your own site, and WordPress shows a page titled Authorize Application, with the name of the application asking to connect.

There are two buttons, "Yes, I approve of this connection" and "No, I do not approve of this connection". If you approve, WordPress creates an application password and passes it directly to the application. If you decline, nothing is created.

• Check that the address bar shows your own domain before you log in, as you would with any login link.
• Check that the application name is the one you were expecting.
• Only approve requests you were told to expect. An approval request you did not ask for should be declined.

This is how WebFixed connects to WordPress sites. The owner approves the request in their own dashboard and no passwords are shared.

How to revoke an application password

1. Go to Users, then Profile, and scroll to Application Passwords.
2. Find the entry by its name and check the Last Used date if you want to see whether it is still in use.
3. Click Revoke next to that entry. It stops working immediately.
4. To remove every one at once, click Revoke all application passwords.

Revoking one has no effect on your own login or on any other application password. It is good practice to revoke a developer’s access once a job is finished and to create a new one if they need to return.

Application password or a separate admin user

The other common way to give a developer access is to create a user account for them under Users, with the Administrator role and their own email address, so they set their own password. Both methods avoid sharing your own login, which you should never do.

• A separate admin user can log in to the dashboard and use every screen, including page builders and plugin settings. This is needed for design and content work that has to be done by eye.
• An application password gives no dashboard login. It suits tools and developers who work through the REST API, and it leaves no extra user account behind to be forgotten about.
• Removing access is one click for an application password. For a user account, delete the user or change their role to Subscriber, and choose to keep their content when WordPress asks.
• Actions made with an application password are recorded under your user account. With a separate user, activity logs show the developer’s own name, which is clearer if several people work on the site.

Related questions

Can someone log in to my dashboard with an application password?

No. The normal WordPress login page rejects application passwords. They are only accepted by the REST API and, where enabled, XML-RPC.

Why can I not see Application Passwords on my profile page?

The site may not be using https, which WordPress requires for this feature, or a security plugin may have switched it off. Check your security plugin’s settings and confirm the site address starts with https.

Can I limit what an application password is allowed to do?

Not within the password itself. It inherits the role of the user who created it, so to limit access, create a separate user with a lower role such as Editor and generate the application password from that account.