WordPress Application Passwords Missing? A Safe Troubleshooting Guide
The Application Passwords section may be missing from a WordPress user profile, or a generated credential may fail to authenticate. Use these checks to distinguish HTTPS, policy, account and request problems without disclosing secrets.
What the feature does
WordPress Application Passwords provide separate revocable credentials for external API integrations. They are tied to a specific WordPress user and are not the password used for ordinary dashboard login. A credential should be used only for an integration that actually needs it, then revoked when no longer needed.
WordPress added core Application Password support in version 5.6. The default feature is intended for HTTPS connections, but hosting configuration and site-level filters can affect whether it appears. See the WordPress Application Passwords documentation for the current core behavior.
If the profile field is missing
First open the intended WordPress user’s profile rather than a global settings page. Confirm the site is using HTTPS and that WordPress recognizes the request as secure. Hosting proxies can create situations where a public HTTPS website is not correctly recognized by its underlying WordPress installation.
Next inspect whether a security plugin, organization policy or custom code disables Application Passwords. WordPress exposes filters that administrators can use to control availability; the absence of the field does not establish a defect in the AI connector. Do not disable a protection without understanding why it was applied.
If a generated password is rejected
An Application Password is typically shown only at creation, so copy it to a trusted credential manager immediately. Verify that the user name, Application Password, HTTPS site host and API route match. Do not substitute your main dashboard password. A proxy or firewall can remove the HTTP Authorization header; diagnose that behavior without sending any token to a support agent.
Test the smallest authorized request, such as reading the authenticated user at /wp-json/wp/v2/users/me. A failed identity request suggests a transport or credential problem; a successful identity request followed by a 403 when editing points toward a separate permission problem.
Secure credential lifecycle
Name credentials by client and purpose, separate staging from production, and revoke obsolete credentials after role changes or decommissioning. Limit each connected WordPress user’s capabilities to the tasks the integration must perform. Maintain a record of which account owns each integration without storing secrets in that inventory.
If you need a broader diagnostic, follow the 401/403 troubleshooting guide and WPBridge Studio connection checklist. Never publish your full Application Password, access token, or raw Authorization header as part of a help request.
Frequently asked questions
Can I use my regular WordPress password instead?
Use a dedicated Application Password for supported external REST integrations rather than exposing the main account password.
Does a valid Application Password give Administrator access?
No. The authenticated request still operates with the capabilities of the associated WordPress user.
Should I make a new Application Password for every AI tool?
Separate revocable credentials by integration and purpose where practical, and audit them periodically.
Related WordPress AI resources
See product features, documentation and technical support. Follow authorized WordPress access and verify any production change.