Correct WordPress file permissions are usually 755 for directories and 644 for regular files, with wp-config.php restricted further to 440 or 400 where your host allows it. Those numbers only work properly when the files have the right owner, so fix ownership and access together rather than opening everything up with 777.
Permissions are one useful layer in WordPress hardening. They cannot replace a cleanup, updates, strong credentials, or plugin management.
Start with the standard WordPress permission baseline
For most WordPress sites, directories should be 755 and files should be 644. This lets the owner read, write, and enter directories, while the web server and other users can read the files needed to serve the site.
Permission numbers have three digits. The first applies to the file owner, the second to the group, and the third to everyone else. In the common settings, 7 means the owner can read, write, and enter a directory; 5 means others can read it and enter it. For files, 6 lets the owner read and write, while 4 gives others read-only access.
Use these as a practical baseline:
- Directories:
755 - Regular files:
644 wp-config.php:440or400if the web server can still read it- Executable scripts that specifically require it: follow the vendor or host documentation, rather than making all PHP files executable
wp-config.php contains database credentials, authentication keys, and other sensitive settings. 440 commonly permits the owner and group to read it but prevents writes. 400 permits only the owner to read it. Either can be a good choice, but only after confirming WordPress still connects to its database and the host's PHP process can read the file.
Do not assume every file needs exactly the same mode. A host that uses a separate service account for PHP, a managed WordPress platform, or a deployment tool may use a different ownership and group model. The goal is simple: WordPress and its approved update process have the access they need, while unrelated users and processes do not.
Ownership matters as much as the permission number
File ownership is often the real reason a WordPress site cannot update plugins, install media, or write a cache file. The permissions can look correct in a control panel while the web server is still unable to write because the files belong to a different user.
On a typical Linux host, a file has an owner and group as well as a mode. For example, a site owner's deployment account may own the files, while PHP runs as that same account. In that setup, 644 files and 755 folders usually work well. On another host, PHP may run under a shared web-server account or a host-managed account. The host may need to set the group, ACL, or ownership for its own model.
This is why changing folders to 777 sometimes appears to solve a problem. It lets every local account write, masking an ownership problem and exposing the site to unnecessary changes from other processes on the server.
If an update or upload fails, check who owns a few representative paths: the WordPress root, wp-content, wp-content/uploads, and the file that fails. In a shell, ls -ld wp-content wp-content/uploads shows the directory mode and owner, and ls -l wp-config.php shows the file details. Your hosting file manager may show the same information in its permissions or ownership panel.
Do not run chown based on a guess. An incorrect owner can take the site offline or prevent WordPress updates. Managed hosts often do not permit ownership changes at all, and that is normal. Ask support which user and group should own the site files, and whether PHP runs as your account, before changing it.
Check permissions before you change them
Make a current backup of files and the database before bulk changes. Permissions do not normally alter file contents, but a rollback point helps if a host-specific configuration reacts badly or reveals a separate ownership problem.
First, confirm that you are in the WordPress installation directory, not a parent directory that contains several sites. You should see wp-admin, wp-includes, wp-content, and wp-config.php. Then inspect a small sample with find . -maxdepth 2 -type d -printf '%m %p\n' where GNU find is available, or inspect individual paths with ls -ld on systems that do not support -printf.
Look for directories that are world-writable, usually modes such as 777, 775, or 757 when the final digit permits writing. A permission audit should also look for unexpected PHP files in wp-content/uploads, unfamiliar administrator accounts, and unapproved plugins. Those are more useful indicators of compromise than a mode number by itself. Our guide to scanning WordPress for malware explains where to look when you suspect a problem.
Before correcting a broad set of files, make sure the site is not actively compromised. An attacker with administrator or server access can simply change the permissions back. For a suspected infection, preserve evidence and work from a cleanup plan such as how to fix a hacked WordPress site.
Apply 755 to folders and 644 to files carefully
Once ownership is confirmed and you have a backup, use find from the WordPress root to change directories and regular files separately. The directory command is find . -type d -exec chmod 755 {} \;. The file command is find . -type f -exec chmod 644 {} \;. Running them separately avoids applying a file mode to directories or a directory mode to files.
These commands affect every matching item below the current directory, including plugin and theme files. Review your location first with pwd, and do not paste a command into a server prompt if it starts from an unfamiliar path. If your site uses a release directory, symbolic links, or a deployment tool, apply permissions through that process instead. A deployment may otherwise overwrite your changes on its next release.
After the general file command, tighten the configuration file with chmod 440 wp-config.php, or try chmod 400 wp-config.php if your host documents that PHP runs as the file owner. Test the public site, the dashboard, an image upload, and one normal update workflow. If WordPress reports that it cannot read wp-config.php, restore the known working mode and ask the host what it supports.
Some setups intentionally need a writable directory for uploads, caching, backups, or a security plugin. That does not mean it should be writable by everyone. Keep the normal mode where possible and resolve write access by setting the appropriate owner, group, or host-provided ACL. Do not make the entire wp-content directory writable just because one plugin has a storage directory.
Prevent PHP from running inside uploads
wp-content/uploads is for media files, not PHP code. Blocking PHP execution there is a useful defense because malicious uploads and backdoors often use that folder to hide a script behind a normal-looking path.
The best implementation is at the web-server level and depends on the server. On Nginx, an administrator can add a location rule that matches PHP files under /wp-content/uploads/ and returns an error instead of passing them to PHP. On Apache, an administrator can apply an equivalent rule in the uploads directory or the virtual-host configuration that denies execution of PHP there. The rule should cover PHP extensions your server sends to the PHP interpreter, not only .php.
Ask your host to make this change if you do not manage the server. Many hosts disable custom web-server rules, use Nginx in front of Apache, or handle PHP through a platform layer. A .htaccess rule is not effective on a server that does not use Apache's .htaccess processing, and adding an Nginx directive to a WordPress file does nothing.
After the rule is live, verify that ordinary images and documents still load. If you find a PHP file already in uploads, do not assume blocking execution has removed the infection. Preserve it for review, search for other backdoors, rotate credentials, and identify how it got there. Finding a WordPress backdoor is a useful next step.
Account for your host's WordPress setup
The correct settings ultimately depend on how your host serves PHP and manages site files. Shared cPanel hosting, a managed WordPress host, a VPS, container hosting, and a Git-based deployment can all use different accounts and restrictions. A provider may also reset permissions after restores, staging pushes, malware remediation, or control-panel actions.
Keep a short record of the working owner, group, special writable paths, and any server rule preventing PHP in uploads. It makes a future migration or incident much easier to review. Recheck permissions after a site move, a host migration, or a recovery from a compromised backup.
When to get help
If permissions keep changing, updates fail after ownership is corrected, or you find executable files in uploads, it is worth investigating the cause rather than loosening access. Our WordPress security audit can review the server and application configuration, and WordPress malware removal is available when the site may already be compromised.