WordPress File Permissions: Setting Them Correctly

WordPress file permissions control which system users can read, write, and execute which files on the server — and when they are wrong, the consequences range from inconvenient to site-breaking. Images stop uploading. Plugins fail to install. The WordPress update process fails silently. In more severe cases, permission problems produce 403 Forbidden errors across the entire site or prevent WordPress from reading its own core files. To fix WordPress file permissions correctly is to restore the precise combination of access rights that allows WordPress to do everything it needs to do — write uploaded media to the uploads directory, update its own files during updates, cache processed page output — while not leaving permissions so open that they become a security liability. I have corrected WordPress file permissions after hosting migrations, after malware cleanup procedures that tightened permissions too aggressively, and on fresh installations where the default transfer permissions were incorrect. This guide covers the correct permission values, every method to check current permissions and fix WordPress file permissions that are wrong, and the specific cases that require special handling. You’ll find the complete rundown in our Complete Guide to WordPress How.

Understanding WordPress File Permissions — What the Numbers Mean

Linux file permissions use a three-digit numeric system where each digit represents the access level for a different category of user: the file owner, the owner’s group, and all other users. Each digit is a sum of three possible values: 4 (read), 2 (write), and 1 (execute). Understanding this system is what makes it possible to fix WordPress file permissions with confidence rather than trial and error.

Permission	Numeric Value	What It Allows	Standard WordPress Use
Owner: read+write; Group: read; Others: read	644	Owner can read and write; group and others can only read	Standard for all WordPress files (.php, .css, .js, .htaccess)
Owner: rwx; Group: r-x; Others: r-x	755	Owner can read, write, and traverse; group and others can read and traverse	Standard for all WordPress directories
Owner: read+write; Group: none; Others: none	600	Owner can read and write; no one else has any access	wp-config.php for maximum security
Owner: rwx; Group: rwx; Others: rwx	777	Everyone on the server can read, write, and execute	Never appropriate for WordPress on a shared server

The standard WordPress permission configuration that the WordPress documentation recommends: all PHP and other files at 644, all directories at 755, and wp-config.php at 600 or 640. These values allow the web server to read all files (necessary for serving WordPress to visitors), allow the PHP process to write to directories where it needs write access (uploads, cache directories), and prevent any user other than the owner from modifying files (a security protection against privilege escalation on shared servers).

Permissions that are too restrictive — directories at 700, files at 600 — prevent the web server from reading files it needs to serve, causing 403 Forbidden errors and failed uploads. Permissions that are too permissive — 777 on files or directories — allow any user or process on the server to write to WordPress files, which is a significant security risk on shared hosting where multiple accounts share the same server. The goal when you fix WordPress file permissions is hitting the precise middle: accessible enough for WordPress to function, restricted enough to maintain security.

How to Check Current WordPress File Permissions

Before you fix WordPress file permissions, confirming the current state of permissions across the installation identifies exactly which files and directories have incorrect values and prevents unnecessary changes to permissions that are already correct.

The methods to check current permissions:

1. Via FTP client (FileZilla): Connect to the server and navigate to the WordPress root. In FileZilla’s file listing, the permissions column shows the numeric value (or symbolic representation like rwxr-xr-x) for each item. Right-clicking any item and selecting File Attributes shows both the numeric value and a checkbox representation that makes reading the values intuitive. Check the WordPress root directory, the wp-content directory, and the uploads directory as the three most critical locations.
2. Via cPanel File Manager: Navigate to the WordPress root in the File Manager. The Permissions column in the file list shows the current value. Click any item and view its File Information in the right panel for a detailed breakdown.
3. Via SSH: The ls -la command in any directory shows the permissions, owner, and group for every item. The permissions display as a 10-character string like -rw-r--r-- (for 644) or drwxr-xr-x (for a directory with 755). For a recursive permission check of the entire WordPress installation: find /path/to/wordpress -not -perm 644 -not -type d | head -20 shows the first 20 files not at 644 permissions.
4. Via WordPress Site Health: Tools → Site Health → Status shows a Filesystem Permissions check that flags critical directories with incorrect permissions. This gives a high-level overview but does not show the numeric values for every file.

Fix WordPress File Permissions via FTP

FTP is the most accessible method to fix WordPress file permissions for site owners without SSH access. FileZilla allows changing permissions on individual files, entire directories, or recursively across all items within a directory — which makes it practical to correct permissions across an entire WordPress installation without touching each file individually.

1. Connect to the server in FileZilla and navigate to the WordPress root directory
2. To fix WordPress file permissions on all directories recursively: right-click the WordPress root folder in the remote panel → File Attributes → set the numeric value to 755 → check “Recurse into subdirectories” → select “Apply to directories only” → OK. This sets every directory in the WordPress installation to 755 in a single operation.
3. To fix all file permissions: right-click the WordPress root folder → File Attributes → set numeric value to 644 → check “Recurse into subdirectories” → select “Apply to files only” → OK. This sets every file to 644 regardless of its current value.
4. For wp-config.php specifically: right-click wp-config.php → File Attributes → set to 600 (owner read+write only) → OK. This is a tighter permission than the standard 644 and is appropriate for the configuration file that contains database credentials.
5. For the uploads directory: right-click wp-content/uploads/ → File Attributes → set to 755 → check “Recurse into subdirectories” → “Apply to directories only” → OK. Then repeat for “Apply to files only” → OK. The uploads directory needs to be writable by the PHP process for media uploads to work.
6. Test the site: upload an image in the WordPress media library to confirm write access works, load a front-end page to confirm read access works, and check that no 403 errors appear after you fix WordPress file permissions.

The recursive permission change via FileZilla is the most efficient way to fix WordPress file permissions across an entire installation in one session, particularly after a migration where files transferred with incorrect ownership or permissions. The two-step approach — directories first with one recursive operation, then files with another — ensures both components are addressed without requiring individual file selection.

Fix WordPress File Permissions via SSH — The Fastest Method

On hosting environments with SSH access, two commands fix WordPress file permissions across the entire WordPress installation in seconds, regardless of installation size:

# Fix all directory permissions to 755
find /path/to/wordpress -type d -exec chmod 755 {} ;

# Fix all file permissions to 644
find /path/to/wordpress -type f -exec chmod 644 {} ;

Replace /path/to/wordpress with the actual absolute path to your WordPress root — typically something like /home/username/public_html on cPanel hosting. These two commands recursively find every directory and every file in the WordPress installation and set their permissions to the correct values. For an installation with thousands of files, the FTP method takes minutes while the SSH method completes in seconds. After running both commands, set wp-config.php separately to 600:

chmod 600 /path/to/wordpress/wp-config.php

On managed WordPress hosts like Kinsta, WP Engine, or Cloudways that provide SSH access through their dashboards, these commands are available from the terminal section of the hosting control panel. Managed hosts often maintain correct permissions automatically, but after a plugin-based migration or a manual file transfer, running the permission reset commands is a reliable way to ensure the installation’s permissions conform to the standard after you fix WordPress file permissions that may have been set incorrectly during the transfer.

The Uploads Directory — Special Permission Considerations

The wp-content/uploads/ directory requires special attention when you fix WordPress file permissions because it has a different security balance than the rest of the WordPress installation. Unlike core files and plugins — which should be readable but not writable by the web server process — the uploads directory must be writable by the PHP process to allow media uploads. This writable requirement creates a security consideration that does not exist for read-only directories.

The standard 755 permission on uploads directories allows the PHP process (which typically runs as the web server user) to write new files when uploads occur. This is the correct balance for most hosting configurations. However, on shared hosting where PHP runs as the site owner rather than the web server user (suPHP or PHP-FPM configurations), 755 is sufficient and 777 is unnecessary — in fact, 777 on the uploads directory creates a specific risk: it allows any PHP code running on the server (including malware from other accounts on the same shared server) to write files to your uploads directory.

Adding a security enhancement after you fix WordPress file permissions on the uploads directory: place a custom .htaccess file inside wp-content/uploads/ containing:

# Prevent PHP execution in uploads directory
php_flag engine off
<FilesMatch ".php$">
  Order Deny,Allow
  Deny from All
</FilesMatch>

This prevents any PHP file that is uploaded to the uploads directory from being executed via a browser URL — a common malware upload vector where attackers exploit file upload vulnerabilities to upload a PHP shell script and then execute it by navigating to its URL. The uploads directory needs to be writable for image uploads to work, but those uploaded files should never be executed as PHP. This .htaccess addition closes the execution pathway without affecting legitimate upload functionality.

Preventing WordPress File Permission Problems After Server Changes

The scenarios most likely to produce incorrect WordPress file permissions that need to be fixed are predictable: hosting migrations, FTP transfers that default to umask-based permissions rather than matching the source, malware cleanup procedures that set all permissions to read-only as a remediation step, and server PHP version upgrades that change the user/group context that PHP runs under. Knowing these triggers makes it straightforward to proactively check and fix WordPress file permissions immediately after any of these events rather than discovering the problem through user-reported errors.

After any hosting migration: run the SSH recursive chmod commands (or the FTP recursive attribute change) as the first post-migration verification step, before any functional testing. This ensures the permission baseline is correct before you test whether uploads, updates, and caching work correctly — if permissions are wrong, those tests fail and the cause is not immediately obvious without checking permissions first.

After malware cleanup: professional malware removal services sometimes set permissions to 444 (read-only for all users) or 400 (read-only for owner only) on all files as an aggressive remediation measure. This stops the malware from writing new files but also stops WordPress from functioning normally — updates fail, uploads fail, and caching cannot write its cache files. After malware cleanup, always verify that you need to fix WordPress file permissions back to the standard values before testing whether the site is functioning correctly again.

Our guide on fixing the WordPress 403 forbidden error covers permission-caused 403 errors in depth — the specific error that most commonly results from permissions that are too restrictive and the fastest path to identifying whether file permissions or .htaccess rules are responsible. Our guide on fixing the WordPress image upload HTTP error covers the upload-specific permission problem in the uploads directory — the most common functional symptom of needing to fix WordPress file permissions on the wp-content/uploads directory specifically. The WordPress documentation on changing file permissions covers the correct values for every WordPress file type and directory with the rationale for each — the authoritative reference for the standard WordPress permission structure. If this sounds familiar, How to Fix WordPress Redirect Loop Safely With Proven Recovery Steps is worth a look.