WordPress Application Passwords – How to Set Up & Use Them

If you need to connect an external app to your WordPress site, whether that’s Zapier, the WordPress mobile app, a custom REST API integration, a CI/CD deploy script, or WP-CLI on a remote machine, Application Passwords are how you do it without handing over your real admin password.

The feature shipped in WordPress 5.6 in December 2020 and has quietly become the standard way to authenticate against the REST API. This guide walks through what they are, how to create one, the most common gotcha that breaks them on shared hosting, and where they fit alongside other auth methods like passkeys and OAuth.

What Are WordPress Application Passwords?

A WordPress Application Password is a long randomly-generated password tied to a specific user account that’s intended for use by an external application instead of you logging in by hand. The password itself is 24 characters of random letters, and WordPress hashes it before storing it (the hash lives in a serialized field on the user record in the wp_users table, similar to your main password).

You don’t use Application Passwords to log into wp-admin in a browser. They only work via HTTP Basic Auth on the WordPress REST API, XML-RPC (if enabled), and WP-CLI commands that hit your site over HTTP. The dashboard login still requires your normal password.

These application passwords are much more secure than sharing your main password because:

• Each one is named (“Zapier”, “Mobile App”, “Deploy Script”) so you can see at a glance what’s authenticated to your site.
• You can create multiple passwords per user and revoke any one of them without affecting the others. Useful when one integration breaks or gets compromised.
• They survive a password reset on your main account, so changing your admin password doesn’t break every connected integration.

This comes in handy when connecting productivity tools like Zapier or automating tasks based on your website’s activity. Instead of sharing your WordPress credentials, you create an application password, give that to Zapier (as an example), and integrate your site securely.

If you’re serious about ensuring your site’s security, you may also want to learn about additional tips like how to change your WordPress login URL to make your site even more secure.

How to Set Up a WordPress Application Password

Ready to get a new application password for an app integration? Let’s go over the step-by-step process inside your WordPress dashboard:

1. Log in to your WordPress dashboard (as an admin). You can usually do this by navigating to yourwebsite.com/wp-admin.
2. Once logged in, find Users in your dashboard, then click on Profile.
3. Scroll down until you see the “Application Passwords” section.
4. Now you’ll be able to see an option to create a new application password.

Let’s say you’re integrating with Zapier. To generate a password for it, simply:

• Type “Zapier” into the application name field.
• Hit the button to generate a new password.
• Your new password (a randomly generated string) will be shown on screen. Copy this password for use in Zapier.

This password now connects the two apps without needing your main login password. If you reset your main WordPress login later, the connection to Zapier remains intact.

If at any point you decide to stop using this service, WordPress makes it extremely easy to revoke that password and stop the app from accessing your site.

You can also remove passwords individually instead of resetting all of them, which keeps every other integration on your site working.

---

Using an Application Password with the REST API

Once you have an Application Password, you authenticate REST API requests with HTTP Basic Auth: your username and the password (with or without spaces, both work). A canonical curl example to fetch your draft posts:

curl -u "your_username:xxxx xxxx xxxx xxxx xxxx xxxx" \
  "https://yoursite.com/wp-json/wp/v2/posts?status=draft&context=edit"

Or to publish a new post programmatically:

curl -u "your_username:xxxx xxxx xxxx xxxx xxxx xxxx" \
  -H "Content-Type: application/json" \
  -X POST "https://yoursite.com/wp-json/wp/v2/posts" \
  -d '{"title":"Hello from the API","content":"Posted via Application Password.","status":"publish"}'

The same Basic Auth pattern works from any HTTP client: Postman, JavaScript fetch, Python requests, GitHub Actions workflows, etc. WordPress treats the request exactly as if the underlying user logged in, so the same role and capability checks apply.

---

When Application Passwords Don’t Work (the HTTP_AUTHORIZATION Gotcha)

The single most common reason Application Passwords fail in real-world setups is this: many shared hosts strip the HTTP Authorization header from incoming requests before they reach PHP, which means WordPress never sees the auth credentials and rejects the request with a 401.

WordPress patched the default .htaccess file to handle this, but if your file was generated before WP 5.6 (or your host runs Nginx, which doesn’t read .htaccess), you may need to add it manually. The exact line:

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

It goes inside the # BEGIN WordPress block, right after RewriteEngine On. Re-saving your Settings -> Permalinks page also forces WordPress to regenerate the file with the modern block.

If you’re still hitting 401s after that, enable WordPress debug mode: the underlying error in /wp-content/debug.log will tell you whether WordPress is even seeing the credentials, or rejecting them for another reason (wrong username, password mismatch, user lacks the capability for the endpoint).

---

Managing Application Passwords

Once you’ve successfully created one, it’s worth paying close attention to how application passwords are managed. Here are some best practices for managing the security of your website when working with them:

• Regularly review active passwords to ensure you’re only giving access to services you are actively using.
• Keep a record of which apps you’ve generated credentials for. If you lose track, WordPress makes it quick to check by revisiting the Application Passwords section.
• Revoke unused credentials as soon as you no longer need those services. You can easily click to revoke an application’s password, which will immediately stop it from accessing your website.

This simple approach makes security far more manageable, especially when you’re working with several third-party integrations. To further enhance the protection of your WordPress login process, you can also follow some additional WordPress user management tips to keep your site’s user roles and permissions under control.

Why You Should Use Application Passwords

Wondering if it’s really worth the effort to use application passwords? Here’s why the answer is yes:

• Better Security: Your WordPress admin password is sacred. It’s far better to entrust external apps with an application password that doesn’t grant total control of your site.
• Control: Generating individual passwords allows precise control over which applications or services can access your website, and you have the power to revoke them instantly.
• Simplicity with Automation: Many new WordPress users will eventually want to automate repetitive tasks, such as integrating with mailing services, form apps, etc. Using application passwords helps streamline various workflows without interrupting other external connections when you update your main WordPress password.

The system is designed to keep things safe and simple at the same time. Real-world use cases that depend on Application Passwords:

• WP-CLI from a remote machine: when you SSH into a different server and need to manage your WordPress site over HTTP rather than from inside its filesystem.
• The official WordPress mobile app: handles login via Application Passwords under the hood.
• Deploy scripts (GitHub Actions, GitLab CI, Vercel): publishing posts or syncing content from a static site to WordPress automatically.
• Zapier, Make, n8n, Pipedream: any low-code automation tool that needs to read or write WordPress content.
• Custom integrations: anything you build yourself that needs to query the REST API as a logged-in user.

For the human-login side of WordPress security, passkeys have become the modern alternative to typing a password into the wp-admin login screen. Application Passwords and passkeys solve different problems and work alongside each other: passkeys for you, Application Passwords for everything else.

---

Frequently Asked Questions

---

Wrapping Up

Application Passwords have quietly become the boring-and-correct way to give external tools access to your WordPress site. Generate one per integration, name it so you remember what it’s for, revoke it the moment you stop using the service, and never paste your real admin password into a third-party form again.

If you’re hitting 401s after creating a password, the underlying cause is almost always the HTTP_AUTHORIZATION header issue covered above, plus possibly your wp-config.php debug settings if you want to see exactly what WordPress is rejecting. And if you want to lock down your own login on top of all this, WordPress passkeys are the modern complement.