File & Directory Permissions: The Correct Numbers

Our hardening checklist mentions file permissions in a couple of sentences, because in a list of a dozen changes that's all the room it gets. This article is the other end of that same topic — what the numbers actually mean, why WordPress.org recommends the specific values it does, what actually happens when a permission is wrong in either direction, and how to fix it if you don't have SSH access.

What a permission number like 644 actually means

Every file and directory on a Linux server (which is what almost all WordPress hosting runs on) has three sets of permissions: what the owner can do, what the group can do, and what everyone else on that server can do. Each set can allow read, write, or execute, and each of those is worth a number: read is 4, write is 2, execute is 1. Add the ones that apply and you get a single digit per group.

So 644 breaks down as:

• 6 (4+2) for the owner — read and write
• 4 for the group — read only
• 4 for everyone else — read only

And 755 is owner: read/write/execute (7), group: read/execute (5), everyone else: read/execute (5). The execute bit means something different for a directory than a file — for a directory, "execute" is actually what lets you look inside it and access its contents at all, which is why directories need it and plain files usually don't.

What WordPress.org actually recommends

This is worth stating precisely, because a lot of hosting tutorials round it off or state it with more confidence than the situation deserves. WordPress's own Advanced Administration Handbook is explicit that there's no single universal answer — the right value depends on your specific server configuration, and it says permissions "will be different from host to host." The one thing it states as a hard rule regardless of setup: no directory should ever be set to 777, including your uploads folder.

For the common case — shared hosting running suexec, which covers a large share of ordinary WordPress hosting — the handbook gives a direct, specific answer:

Directories: 755 (or 750, stricter)
Files, generally: 644 (or 640, stricter)
wp-config.php specifically: 440 or 400

That last exception matters more than it might look. A freshly uploaded file typically lands at 644, and 644 is genuinely fine for almost everything — template files, images, most PHP files. But wp-config.php holds your database username and password, your authentication keys and salts, and any API keys you've added as constants for a plugin. Leaving it at 644 means every other user account on a shared server can read it, not just yours. Tightening it to 440 (owner and group can read, nobody can write) or 400 (only the owner can even read it) closes that specific gap without touching anything else.

If your hosting setup isn't suexec-based, the handbook's guidance is different and more conservative: start restrictive, and loosen only as far as is needed for the site to actually function, rather than starting from a fixed number. That's a real distinction — if you're not sure which category your host falls into, ask them, because applying the suexec numbers on a non-suexec setup can either do nothing useful or break functionality depending on how your server is configured.

Why "just chmod everything to 777" is a bad fix, not a shortcut

777 means read, write, and execute for the owner, the group, and every other account on the server. On a lot of shared hosting, "every other account on the server" isn't a hypothetical — it can include other customers' sites, or any process running under a different user than yours. A world-writable file isn't just editable by your WordPress install anymore; it's editable by anything on that machine that can reach the filesystem, including a compromised neighboring site's malware looking for an easy place to plant a backdoor.

The reason 777 shows up as "the fix" so often is that it usually does make a permission-denied error disappear — WordPress can suddenly write the file it couldn't before, an upload succeeds, a plugin installs. That's exactly what makes it a trap: it looks like a solution because the symptom goes away, while the actual cause (the wrong owner, or a permission set too tight in the wrong specific place) is still there. The safer version of "make this work" is to figure out which specific file or directory needs write access and grant that narrowly, not to open everything.

Checking and changing permissions without SSH

You don't need command-line access to do this correctly. Two practical paths:

• An SFTP client (FileZilla, Cyberduck, or similar). Connect with the credentials your host provides, right-click any file or folder, and look for "File permissions" or "Attributes." Most SFTP clients show the same numeric value (644, 755, etc.) alongside checkboxes for each read/write/execute bit, so you can set it directly as a number.
• Your hosting control panel's file manager. cPanel, Plesk, and most managed-WordPress dashboards include a file manager with the same right-click-and-set-permissions option, no separate software needed.

If you do have terminal access, the commands are straightforward — apply directory and file permissions separately, since they need different values:

find /path/to/site -type d -exec chmod 755 {} \;
find /path/to/site -type f -exec chmod 644 {} \;
chmod 440 /path/to/site/wp-config.php

The balance: too strict breaks things too

It's tempting to treat "tighter is always safer" as a universal rule here, and it isn't. WordPress's auto-update system, one-click plugin/theme installs, and the media uploader all need the web server's user account to have write access to specific directories — wp-content, wp-content/uploads, wp-content/plugins, and wp-content/themes in particular. Lock those down too aggressively (say, removing group write entirely when your setup actually needs it) and you'll see auto-updates silently fail, or get a "could not create directory" error the moment you try to upload an image.

The practical result: don't treat this as "run the chmod commands once and never think about it again." If you tighten permissions and something legitimate — an update, an upload, a plugin install — starts failing right after, that's usually the permission change, not a coincidence. Loosen the specific directory involved back to what WordPress actually needs, rather than reversing the whole change.