{"id":674,"date":"2026-10-19T12:34:47","date_gmt":"2026-10-19T12:34:47","guid":{"rendered":"https:\/\/keyworth.co\/blog\/how-to-create-a-wordpress-application-password"},"modified":"2026-10-19T12:34:47","modified_gmt":"2026-10-19T12:34:47","slug":"how-to-create-a-wordpress-application-password","status":"publish","type":"post","link":"https:\/\/keyworth.co\/blog\/how-to-create-a-wordpress-application-password","title":{"rendered":"How to Create a WordPress Application Password"},"content":{"rendered":"<p><script type=\"application\/ld+json\">{\"@context\":\"https:\/\/schema.org\",\"@type\":\"Article\",\"headline\":\"How to Create a WordPress Application Password\",\"description\":\"Create a WordPress application password from Users, then Profile, in your dashboard, and use it to connect external tools to your site securely.\",\"image\":\"https:\/\/kzvpvjjbqvmgluaudrhi.supabase.co\/storage\/v1\/object\/public\/article-images\/9815b36f-2a34-45b5-a5cd-e6f161a91d9f\/featured.jpg\",\"author\":{\"@type\":\"Person\",\"name\":\"Editorial Team\"},\"datePublished\":\"2026-10-19T12:34:38.303Z\",\"publisher\":{\"@type\":\"Organization\",\"name\":\"Keyworth\",\"url\":\"https:\/\/keyworth.co\"}}<\/script><br \/>\n<script type=\"application\/ld+json\">{\"@context\":\"https:\/\/schema.org\",\"@type\":\"FAQPage\",\"mainEntity\":[{\"@type\":\"Question\",\"name\":\"What WordPress version is required?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"WordPress requires version 5.6 or higher to use this authentication feature natively. If your site runs an older version, you must upgrade your core installation to access the functionality.\"}}]}<\/script><\/p>\n<p>To create a WordPress application password, log into your site dashboard, go to the Users menu, click Profile, scroll down to the Application Passwords section, type a name for the connection, and click Add New Application Password. This generates a unique 24-character string that external systems use to communicate securely with your website. If you are building automated publishing workflows or connecting third-party mobile apps to your site, you will need this specific credential to authenticate your requests without exposing your primary account password.<\/p>\n<h2>Core Functionality and Prerequisites<\/h2>\n<p>Before you attempt to generate credentials, your website environment must meet two non-negotiable requirements. First, your site must run on a modern core release version. WordPress integrated this feature natively into the core software starting with version 5.6. If your installation runs an older version, the feature simply will not exist in the dashboard.<\/p>\n<p>Second, the WordPress REST API enforces a strict HTTPS SSL requirement. The system automatically disables the generation interface and rejects basic authentication attempts over standard HTTP. This prevents malicious actors from intercepting credentials in plain text across open networks. The only exception to this SSL rule is when the environment is configured as a local development server running on localhost, which allows developers to test API endpoints locally without generating valid SSL certificates.<\/p>\n<p>These credentials operate as revocable, per-application passwords linked directly to a specific user account.  They are designed exclusively for API requests and cannot be used to log into the visual WordPress admin dashboard.  According to the <a href=\"https:\/\/aamportal.com\/article\/wordpress-application-passwords-invisible-credentials-to-monitor\/\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">AAM Portal documentation<\/a>, the system stores these credentials as hashed values rather than plain text.<\/p>\n<p>Specifically, WordPress stores them as salted hashes inside the <code>wp_users<\/code> database table.  Because of this one-way hashing mechanism, the plaintext string is visible only during initial creation.  Once you close the screen, neither you nor a database administrator can retrieve the original password.<\/p>\n<h2>Navigating the User Profile<\/h2>\n<p>To begin the creation process, sign in to the dashboard as an administrator by accessing your standard login screen at yourwebsite.com\/wp-admin in a web browser. The credentials you use to log in will dictate whose account you can modify.<\/p>\n<p>Once logged in, open the left-hand navigation in the WordPress admin panel, go to Users, and select Profile. If you are a site administrator creating a connection for a different team member or a dedicated bot account, navigate to Users and select All Users, then click Edit under the targeted user account instead. The <a href=\"https:\/\/docs.tryprofound.com\/integrations\/wordpress\/create-an-application-password-in-word-press\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">Profound documentation<\/a> notes that you must scroll past the standard account management and theme options to find the dedicated application passwords block at the bottom of the profile screen.<\/p>\n<p>Before you create the password on an administrator account, apply the principle of least privilege. You should avoid generating application passwords for admin-level users unless the external script absolutely requires full administrative control over the site. For routine integrations that only need to draft or publish content, you should create a dedicated new user account with the Author or Editor role. Generating the password under this restricted account ensures that if the third-party platform suffers a data breach, the compromised credential can only publish posts rather than delete plugins, modify themes, or wipe the entire database.<\/p>\n<h2>Generating the Application Password<\/h2>\n<p>On your Profile screen, enter a distinct label into the empty text box. Choose an explicit label like Zapier Content Sync or Python Script. As <a href=\"https:\/\/smartwp.com\/wordpress-application-passwords\/\">SmartWP<\/a> notes, an app password lets you connect external tools like Zapier without handing over your real password. Never use generic labels. Clear names help you identify exactly which tool to revoke if an integration breaks.<\/p>\n<p>Click the Add New Application Password button. WordPress generates a password that is 24 characters long without special characters. The dashboard displays this key in four-character chunks separated by spaces. You can paste the code with or without those spaces into your API calls.<\/p>\n<p>Copy the generated string right away. According to the <a href=\"https:\/\/docs.tryprofound.com\/integrations\/wordpress\/create-an-application-password-in-word-press\/\">Profound documentation<\/a>, WordPress will not show this value again after you leave. The core system stores the password as a hash for security. If you close the browser tab without copying the key, you must revoke the entry and start over. Always verify the remote handshake before you close the edit screen.<\/p>\n<h2>Managing Application Permission Boundaries<\/h2>\n<p>External tools require your primary WordPress username alongside the newly generated string. Never use the application label as your username. For instance, an account named editor_jane using a key labelled Profound Integration still authenticates as editor_jane.<\/p>\n<p>Each password inherits the exact capabilities of the linked WordPress user account. Safer credentials do not restrict account authority on their own. A script tied to an Editor profile can delete unpublished drafts or modify existing posts. Create a dedicated user with minimal capabilities before issuing credentials. Avoid attaching automated services to an Administrator profile.<\/p>\n<p>This authentication method enables direct connections for external scripts and headless environments. Developers write background tasks that sync inventory data every night. Marketing teams connect tools like Zapier to create draft posts from spreadsheet rows. Automations run without manual logins.<\/p>\n<p>Engineers connect mobile applications to the site database and authenticate Model Context Protocol servers. Frontend frameworks like Next.js and Astro fetch draft previews through the REST API without standard cookies. Remote calls retrieve content cleanly.<\/p>\n<p>Reliable credential verification matters when managing automated <a href=\"https:\/\/keyworth.co\/blog\/wordpress-seo-content-publishing-a-hands-on-tutorial\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">WordPress SEO content publishing<\/a>. If your external tool fails the authorization check, the site rejects the incoming data immediately. Check your error logs first if publishing jobs fail.<\/p>\n<h2>Fixing Authorization Header Stripping<\/h2>\n<p>Even with a correctly generated password and a valid HTTPS connection, you may encounter 401 Unauthorized errors when your external script attempts to communicate with the WordPress REST API. The most frequent cause of this failure is aggressive server configuration. Many shared hosting environments run CGI or FastCGI setups that automatically strip the <code>HTTP_AUTHORIZATION<\/code> header from incoming requests before they reach the WordPress core.<\/p>\n<p>If you use Apache, you must force the server to pass this header down to the application layer. You can fix this by editing the <code>.htaccess<\/code> file located in your root directory. Open the file and add the directive <code>SetEnvIf Authorization \"(.*)\" HTTP_AUTHORIZATION=$1<\/code> just below the <code>RewriteEngine On<\/code> line. Alternatively, if your server runs Apache 2.4.13 or higher, adding the single line <code>CGIPassAuth On<\/code> achieves the exact same result.<\/p>\n<p>If your server runs Nginx, the configuration requires a different directive. You will need to edit your server block configuration file and add <code>fastcgi_pass_header Authorization;<\/code> into the PHP processing block. This tells Nginx to retain the authentication data when handing the request off to PHP.<\/p>\n<p>Once the server configuration allows the header through, you must format your requests correctly using HTTP Basic Authentication. This requires encoding your username and application password into a Base64 string. In a simple cURL command, the <code>-u<\/code> flag handles this automatically: <code>curl -u \"username:password\" https:\/\/yourwebsite.com\/wp-json\/wp\/v2\/posts<\/code>.<\/p>\n<p>If you are writing a custom script in Python using the <code>requests<\/code> library, you can use the built-in auth parameter: <code>requests.get(url, auth=('username', 'password'))<\/code>.<\/p>\n<p>When building headless frontends in JavaScript using the native <code>fetch<\/code> API, you must construct the header manually. You combine the username and password with a colon, encode the result in Base64 using the <code>btoa()<\/code> function, and prefix it with the word Basic. The exact headers object looks like this: <code>headers: { 'Authorization': 'Basic ' + btoa('username:password') }<\/code>. Providing the header in this exact format ensures the WordPress REST API recognizes the credential.<\/p>\n<h2>Managing and Revoking Credentials<\/h2>\n<p>Security best practices dictate that you should regularly audit all active connections to your website.  The simplest way to audit and revoke credentials is via the WordPress graphical interface.  Returning to the User Profile screen displays a list of all active application passwords associated with that account.<\/p>\n<p>The table shows the name of the application, the IP address that last used it, and the date of its last use.  If you spot an integration that is no longer active, click the Revoke button next to the name.  This immediately invalidates the hash in the database, breaking the connection for any script attempting to use that specific password.<\/p>\n<p>For developers and system administrators managing large multisite networks, checking every individual user profile manually is highly inefficient. Instead, administrators use <a href=\"https:\/\/serverpilot.io\/docs\/guides\/apps\/wordpress\/wp-cli\/\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">WP-CLI management commands<\/a> to handle credentials directly from the server terminal. You can list all active passwords for a specific user ID by typing <code>wp user application-password list 123<\/code> (replacing 123 with the actual user ID).<\/p>\n<p>If an employee leaves the company or a third-party service suffers a security breach, you can destroy a specific token immediately via the terminal using <code>wp user application-password delete 123 &lt;uuid&gt;<\/code>. You can also generate new credentials programmatically during server provisioning by executing <code>wp user application-password create 123 \"New Automation App\"<\/code>, which outputs the new plaintext password directly into your terminal output.<\/p>\n<p>Some highly restrictive enterprise environments prefer to disable this feature entirely to force all traffic through a centralized Single Sign-On (SSO) provider or Oauth server. You can remove the feature globally across the entire WordPress installation by adding a single line of PHP to a custom plugin or a theme&#8217;s functions file. Applying the filter <code>add_filter( 'wp_is_application_passwords_available', '__return_false' );<\/code> hides the generation interface from the user profile screen and instructs the REST API to reject all incoming application password authentication attempts network-wide.<\/p>\n<h2>FAQ<\/h2>\n<h3>What WordPress version is required?<\/h3>\n<p>WordPress requires version 5.6 or higher to use this authentication feature natively. If your site runs an older version, you must upgrade your core installation to access the functionality.<\/p>\n<h3>Where do I find Application Passwords?<\/h3>\n<p>You find them by logging into your WordPress dashboard, opening the Users menu, and selecting Profile. Scroll down past the personal options and account management settings to locate the dedicated section at the bottom of the screen.<\/p>\n<h3>How do I create an app password?<\/h3>\n<p>Type a descriptive name for your external application into the New Application Password Name field, then click the Add New Application Password button. WordPress will instantly generate and display a 24-character string that you must copy and save immediately.<\/p>\n<h3>Why can I not see Application Passwords in my user profile in the Account Management section?<\/h3>\n<p>The interface will not appear if your website is loading over standard HTTP instead of a secure HTTPS SSL connection. Additionally, a security plugin or a custom code filter in your theme may be actively disabling the feature across your network.<\/p>\n<h3>Is there a difference in permissions between a normal password and a new Application Password?<\/h3>\n<p>There is no difference in capability scope between the two credentials. The application password inherits the exact role and permissions of your normal account, but it is restricted to API access and cannot be used to log into the visual wp-admin dashboard.<\/p>\n<p>Creating and managing these credentials properly gives you secure, trackable access points for every external tool connecting to your site. By enforcing strict naming conventions, binding connections to limited-role user accounts, and routinely auditing the access logs in the user profile, you can scale your automated publishing workflows without compromising server security.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Create a WordPress application password from Users, then Profile, in your dashboard, and use it to connect external tools to your site securely.<\/p>\n","protected":false},"author":1,"featured_media":673,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-674","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/keyworth.co\/blog\/wp-json\/wp\/v2\/posts\/674","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/keyworth.co\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/keyworth.co\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/keyworth.co\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/keyworth.co\/blog\/wp-json\/wp\/v2\/comments?post=674"}],"version-history":[{"count":0,"href":"https:\/\/keyworth.co\/blog\/wp-json\/wp\/v2\/posts\/674\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/keyworth.co\/blog\/wp-json\/wp\/v2\/media\/673"}],"wp:attachment":[{"href":"https:\/\/keyworth.co\/blog\/wp-json\/wp\/v2\/media?parent=674"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/keyworth.co\/blog\/wp-json\/wp\/v2\/categories?post=674"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/keyworth.co\/blog\/wp-json\/wp\/v2\/tags?post=674"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}