The safe WordPress file permissions are 644 for files, 755 for directories, and 600 or 400 for wp-config.php, with one big caveat: whether a given number works at all depends on who owns the files. On our test site, wp-config.php kept loading at every setting down to 400 when the web server owned it, but broke at 400 when it was owned by root and the server only had group access. This guide explains what the numbers mean, the right values per file, why ownership decides everything, and why 777 is dangerous.
What the three numbers mean
A permission like 644 is three digits, one each for the owner, the group, and everyone else, and each digit adds up read (4), write (2), and execute (1). So 644 means the owner can read and write (4+2), while the group and everyone else can only read (4). For a directory, “execute” means the right to enter it and list its contents.
That’s the whole system:
- 644 (
rw-r--r--): owner reads and writes; others read. The standard for files. - 755 (
rwxr-xr-x): owner reads, writes, enters; others read and enter. The standard for directories. - 600 (
rw-------): owner reads and writes; nobody else gets anything. For sensitive files. - 400 (
r--------): owner reads only. The tightest useful setting for a file. - 777 (
rwxrwxrwx): everyone can read, write, and execute. Dangerous, as shown below.
The recommended values
The recommended values are 644 for files, 755 for directories, and 600 or 400 for wp-config.php. These are WordPress’s own baseline, and on our test site they matched what a fresh install actually uses.
| What | Permission | Meaning |
|---|---|---|
| Directories | 755 | Owner full; others can enter and read |
| Files | 644 | Owner read/write; others read |
wp-config.php | 600 or 400 | Owner only; no group or public access |
.htaccess | 644 | Same as other files |
When we installed WordPress 7.1.3 fresh and counted, every file was 644, and every directory was 755, with only a couple of exceptions the installer sets itself (test T1b). So on a normal install you rarely need to change file permissions at all; the values above are what to restore to if something, often a plugin or an FTP client, has changed them.
One number you’ll see argued about is 755 versus 775 for directories, or 644 versus 664 for files. The difference is whether the group can write. Which one is correct depends entirely on ownership, which is the part most guides skip.
Why ownership decides everything
Ownership decides everything: the same permission number can be safe or broken depending on who owns the file, because the three digits apply to owner, group, and others, and “who the web server counts as” changes with the setup. This is the single most important thing to understand about WordPress permissions.
We tested wp-config.php at a range of settings under two ownership setups, resetting PHP’s cache between each so the change actually took effect (tests T2b, T3b).
When the web server user (PHP) owns the file, the owner digit is the one that applies to PHP:
| Setting | Home page |
|---|---|
| 644, 640, 600, 440, 400 | works (HTTP 200) |
| 000 | breaks (HTTP 500) |
Every setting down to 400 worked, because 400 still grants the owner read, and PHP is the owner. Only 000, which denies even the owner, broke it.
When root owns the file, and the web server is only in its group, the group digit is the one that applies to PHP:
| Setting | Home page |
|---|---|
| 644, 640, 440 | works (HTTP 200) |
| 400, 600 | breaks (HTTP 500) |
Here, 400 and 600 broke the site because they give the group no access, and PHP is in the group, not the owner. The exact same 400 that was safe in the first setup takes the site down in the second.
This is why “set wp-config.php to 400” is bad advice on its own. On most shared hosting, the web server runs as your user and owns your files (the first setup), so 400 is fine and ideal. On a server where files are owned by root or a deploy user and the web server runs as a separate group member (the second setup), 400 breaks everything. Check who owns your files before tightening, and test after.
Permissions also decide how WordPress updates itself
File ownership also controls whether WordPress can update itself directly or has to ask for FTP details, and this surprises people who tighten permissions and then can’t update. When WordPress updates a plugin, it checks whether the web server can write the files directly.
We tested this over the web, through PHP-FPM as the web server user (test T4c). When the web server owned all the files, WordPress chose the direct update method: it writes files itself, no FTP prompt. When the files were owned by root with the web server only in the group, WordPress chose ftpext: it falls back to asking for FTP or SSH credentials before it will update.
So the “nicer” security setup of root-owned files has a cost: updates stop being one-click and start demanding credentials, which tempts people into loosening permissions or storing FTP details in the config. For most sites, having the web server own the files (with 644/755) is both simpler and safer than root ownership with looser permissions bolted on.
Fixing permissions in bulk
To reset a whole site’s permissions, use find to set files and directories separately, and use the batched form of the command so it doesn’t take forever. Doing files and directories in one sweep is wrong, because they need different values.
From the site’s root folder:
# Directories to 755
find . -type d -exec chmod 755 {} +
# Files to 644
find . -type f -exec chmod 644 {} +
# wp-config.php tighter (check ownership first, per the section above)
chmod 600 wp-config.phpThe + at the end matters. It passes many files to one chmod call instead of running chmod once per file. On our test site of ~5,000 files, the per-file form (-exec chmod 644 {} \;) took 7 seconds; the batched form (-exec chmod 644 {} +) took 0.04 seconds (test T5b). Same result, 170 times faster.
After running these, spot-check a page. If the site breaks, your ownership setup likely needs the group-writable variant (775/664) rather than 755/644; re-read the ownership section and test.
Why 777 is dangerous
Never set anything to 777, because it lets every other account on the server write to your files, and on shared hosting that includes other people’s sites. 777 is the number desperate guides suggest to fix a permissions error, and it does fix it by removing the protection entirely.
We showed the risk directly (test T6). With the uploads folder at 777, a completely unrelated system user wrote a PHP file straight into it. With the folder back at 755, the same write was refused: “Permission denied.” On a shared server, 777 on a folder means any other customer, or anything that compromises any other site on that box, can drop a malicious PHP file into yours and run it. A permissions error is never a reason to reach for 777; it’s a sign the ownership is wrong, which is what to fix instead.
Frequently Asked Questions
What are the correct file permissions for WordPress?
Files should be 644, directories 755, and wp-config.php tighter at 600 or 400. On a fresh install, these are already what WordPress uses, so you rarely need to change them; the values are what to restore to if an FTP client or plugin has altered them. The one caveat is that the safe value for wp-config.php depends on which user owns the files.
Is 777 ever safe for WordPress?
No, never. 777 lets every other account on the server read, write, and execute your files, and on shared hosting that includes other customers. On our test site, an unrelated user wrote a PHP file straight into a 777 uploads folder; at 755, the write was refused. A permissions error means the ownership is wrong, which is what to fix instead.
Why does chmod 400 on wp-config.php break my site?
Because of file ownership. 400 grants read-only access to the file’s owner. If the web server owns the file, that’s fine. But if root owns it and the web server is only in the group, 400 gives PHP no access, and the site breaks with a 500 error, which we reproduced. Check ownership before tightening; use 440 when the server is a group member.
How do I reset all WordPress file permissions at once?
From the site root, run: find. -type d -exec chmod 755 {} + for directories and find . -type f -exec chmod 644 {} + for files, then tighten wp-config.php. Use the + form, not \;: on our 5,000-file test site the batched form took 0.04 seconds against 7 seconds for the per-file version. If the site then breaks, your ownership setup likely needs the 775/664 group-writable values.
The short version of WordPress permissions
The short version: files 644, directories 755, wp-config.php 600 or 400. Never 777. Before tightening wp-config.php, check who owns it: if the web server owns your files, 400 is perfect; if root owns them and the server is a group member, 440 is as tight as you can go without breaking the site. Reset in bulk with find ... -exec chmod ... +, separately for files and directories.
Permissions protect the files; the settings inside wp-config.php protect what’s in them, and the two work together, covered in wp-config.php security settings. For where this fits in the full hardening pass, see the full WordPress security checklist.