WordPress application passwords not showing: the causes and fixes

WordPress application passwords stop showing for one of two reasons: WordPress does not believe the site is served over HTTPS, or some code on the site turns the feature off through the wp_is_application_passwords_available filter. The first case leaves a message in the profile saying the feature requires HTTPS; the second removes the Application Passwords section entirely.

Work through the causes below in order. Each one says what you will see, how to confirm it and the exact fix, and the last section tests the credential once the section is back.

Where should the Application Passwords section be?

It sits near the bottom of Users, then Profile, below Account Management, on WordPress 5.6 or later. It has a heading, a field labelled New Application Password Name and a button labelled Add Application Password. Administrators also see it when editing another user from Users, then All Users.

If you are on WordPress 5.5 or older, the feature does not exist yet, and updating core is the fix. On 5.6 and later, what you see in place of the section tells you which cause you are dealing with:

This mapping comes straight from WordPress core's user-edit.php. The section renders when the feature is available for the user or when HTTPS support is missing, so a missing HTTPS setup shows a message, while a filter that switches the feature off hides the section outright.

Why does WordPress say the feature requires HTTPS?

WordPress only turns application passwords on when is_ssl() returns true, or when the site's environment type is local. The core function is one line: return is_ssl() || 'local' === wp_get_environment_type();. The reason is security: Basic auth sends the password with every request, and over plain HTTP anyone on the network path can read it.

The trap is that a site can load over https:// in the browser while PHP still thinks it is on HTTP. is_ssl() only checks whether the server set $_SERVER['HTTPS'] to on or 1, or whether the request arrived on port 443. When TLS ends at a load balancer, a CDN or a reverse proxy, and the proxy talks to WordPress over plain HTTP, neither is true.

To confirm it, check three things:

1. The site's Settings, then General screen shows both WordPress Address and Site Address starting with https://.
2. Your host or CDN terminates TLS in front of the server (common with load balancers and CDN proxies).
3. The REST index at https://your-site/wp-json/ has an empty authentication key. The integration guide says an empty key means application passwords are unavailable, "perhaps because the request is not over https://."

The fix for a proxy is in WordPress's HTTPS handbook: tell WordPress to trust the X-Forwarded-Proto header your proxy sends. Add this to wp-config.php above the line that says to stop editing:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false ) {
    $_SERVER['HTTPS'] = 'on';
}

Only add it if your proxy really sets that header and strips any value a visitor sends, otherwise a client could claim HTTPS on a plain connection. If the site has no certificate at all, install one before trying anything else in this guide.

Can you use application passwords on a local site without HTTPS?

Yes, if you mark the site as local. WordPress accepts plain HTTP when wp_get_environment_type() returns local, so a development copy on http://localhost can create and use application passwords. Only local counts: development, staging and production all still require HTTPS.

Set it in wp-config.php:

define( 'WP_ENVIRONMENT_TYPE', 'local' );

The wp-config documentation lists the allowed values as local, development, staging and production, and says any other value falls back to production. A typo therefore quietly keeps the HTTPS requirement. Never set local on a public server just to make the section appear.

The integration guide also documents forcing the feature on over HTTP with add_filter( 'wp_is_application_passwords_available', '__return_true' );, and warns that without SSL the password can be seen by an attacker on your network. Treat that as a last resort for closed networks, not a fix for a live site.

Is a plugin or your host disabling application passwords?

If the section is missing completely on an HTTPS site, some code is returning false from the wp_is_application_passwords_available filter. The Advanced Administration Handbook names the usual suspects: "Security plugins, must-use plugins, or custom code may disable Application Passwords via filters." Find the code and switch it off.

Security plugins are the most common source. Wordfence has a setting named "Disable WordPress application passwords"; open Wordfence's All Options page, uncheck it and save. If you run a different security plugin, look through its settings for anything that disables application passwords or restricts the REST API.

To find the code directly, search the whole wp-content folder, including must-use plugins, which load automatically and never appear on the Plugins screen:

grep -rn "wp_is_application_passwords_available" wp-content/

Any match that attaches __return_false or a function returning false is the cause. A match inside wp-content/mu-plugins/ usually belongs to your host, since hosts use must-use plugins to apply platform-wide settings. Ask the host whether you can turn it off before deleting their file, because an update may put it back.

If you cannot search files, deactivate plugins one at a time (security plugins first) and reload your profile after each. The section reappears as soon as the plugin responsible is off.

Why do some users see the section and others don't?

A second filter, wp_is_application_passwords_available_for_user, decides per user. The integration guide shows it being used to restrict the feature to administrators by checking the manage_options capability. If your admin account sees the section but the Author account you made for an integration does not, a filter like that is in place.

Run the same grep for wp_is_application_passwords_available_for_user and widen the condition to include the role your integration uses. The filter receives the user whose profile is open, not the person looking at it, so an administrator editing the Author account sees the section hidden too. Changing who creates the password does not get around it; changing the filter does.

What if the site is behind an HTTP password prompt?

Staging sites are often protected by a server-level username and password prompt (HTTP Basic Authentication). WordPress detects this and replaces the create form with "Your website appears to use Basic Authentication, which is not currently compatible with Application Passwords." Both use the same Authorization header, so they collide.

The fix is to lift the server password for the requests your integration makes, or to test on the live HTTPS site instead. Host-level staging protection usually has an on and off switch in the hosting dashboard.

Two smaller causes produce a missing section too. The section carries WordPress's hide-if-no-js class, so it stays hidden when JavaScript is turned off in the browser. And a site on WordPress older than 5.6 has no such section at all.

How do you test the password once the section is back?

Create a password, then call the current-user endpoint with curl. A 200 response containing your user's id and name means everything works. A 401 names the reason in its code field, which tells you which layer still fails.

curl --user "your-login:abcd EFGH 1234 ijkl MNOP 6789" \
  https://your-site/wp-json/wp/v2/users/me

The last row is the one that looks like a wrong password but is not. WordPress's REST API FAQ says that in a CGI environment "your webserver may be stripping the headers." WordPress's Site Health screen runs a test for this and reports "The authorization header is missing," with a Flush permalinks action that rewrites .htaccess. If that does not help, add the handbook's rule to .htaccess on Apache:

<IfModule mod_setenvif>
SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
</IfModule>

On Nginx with PHP-FPM, add fastcgi_pass_header Authorization; to the FastCGI section of the server block. A firewall or CDN rule can strip the header too, so if both fixes fail, ask your host whether anything in front of PHP removes Authorization from requests to /wp-json/.

With a 200 from /users/me, you can create posts. The guide to publishing through the WordPress REST API continues from here with a draft, categories and a featured image.

Send finished drafts to WordPress without the plumbing

Once the credential works, something still has to write the posts. LaunchScaler's content engine plans a month of articles from your own Search Console queries, writes one a day (thirty a month) from what your product does, in your voice, and puts every draft in your workspace to rewrite, trim or scrap; by default, each one waits for your review before it publishes. WordPress is one of its destinations, with Webflow, Ghost, Shopify, Notion, Medium and a signed webhook for anything else.

It costs $99/mo per website with 3 days free. Compare it with plugin-based writers in AI blog writers for WordPress, or start the engine and the first draft arrives on day one.