WordPress application passwords not showing: the causes and fixes
The Application Passwords section disappears when WordPress can't detect HTTPS or a plugin disables it. Every cause, how to spot it, and the exact fix.
LLaunchScaler·Published ·8 min read
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:
What the profile shows
Most likely cause
Jump to
"The application password feature requires HTTPS, which is not enabled on this site."
WordPress does not detect HTTPS
The HTTPS cause
No section at all
A plugin, host or code filter disables the feature
The filter cause
No section for one user, present for another
Questions, answered
What people ask about this
01
Why are application passwords not showing in my WordPress profile?
Either WordPress does not detect the site as HTTPS, or a plugin, must-use plugin or theme code returns false from the wp_is_application_passwords_available filter. In the first case the section shows a message saying the feature requires HTTPS; in the second it disappears completely.
"Your website appears to use Basic Authentication, which is not currently compatible with Application Passwords."
The site sits behind an HTTP password prompt
The Basic Authentication cause
The section appears, but API requests return 401
The server strips the Authorization header
The last section
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:
The site's Settings, then General screen shows both WordPress Address and Site Address starting with https://.
Your host or CDN terminates TLS in front of the server (common with load balancers and CDN proxies).
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:
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:
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.
"The provided password is an invalid application password."
Copy the password again, or create a new one
invalid_username or invalid_email
Unknown username, or unknown email address
Use the account's login name or email address, not its display name
application_passwords_disabled
"Application passwords are not available."
A filter is still active; go back to the filter cause
application_passwords_disabled_for_user
Not available for your account
A per-user filter; go back to that cause
rest_not_logged_in
"You are not currently logged in."
The Authorization header never reached WordPress
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:
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/.
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.
Do WordPress application passwords work without HTTPS?
Only on a site whose environment type is local, set with define( 'WP_ENVIRONMENT_TYPE', 'local' ) in wp-config.php. On any other site WordPress requires HTTPS, and forcing it on over plain HTTP exposes the password on the network.
03
How do I enable application passwords disabled by Wordfence?
Wordfence has a setting named Disable WordPress application passwords. Open Wordfence's All Options page, uncheck that setting, save, and reload your profile page.
04
How do I test a WordPress application password?
Run curl --user "username:application-password" https://your-site/wp-json/wp/v2/users/me. A 200 response with your user's details means it works; a 401 body names the reason, such as incorrect_password or rest_not_logged_in.
05
Why does my application password return 401 even though it is correct?
The server is probably stripping the Authorization header before PHP sees it, which WordPress reports as rest_not_logged_in. Site Health shows 'The authorization header is missing', and the REST API handbook gives the Apache and Nginx settings that pass the header through.
Answer in the first two sentences, write 40 to 60 word passages under question headings, and back claims with sources and statistics. Rules with examples.
Competitor alternatives and X vs Y pages that hold up: every claim sourced and dated, one table with the same fields, who each suits, checked quarterly.
