WordPress File Permissions — Security Best Practices Explained

File permissions are one of those things that most WordPress site owners never think about — until something goes wrong. Either your site gets hacked because permissions were too loose, or a plugin can't write to a directory because permissions were too tight, or your hosting provider sends you a stern email about a "security misconfiguration." I've been dealing with Linux file permissions since the early 2000s, long before I started working with WordPress, and I can tell you that understanding this one concept will save you from a surprisingly large number of headaches. It's not complicated once you know what the numbers mean, and getting it right is one of the most impactful things you can do for your site's security.

Here's why it matters in plain terms: file permissions control who can read, modify, and execute files on your server. If permissions are too permissive, anyone — including malicious scripts — can modify your WordPress files, inject code, or read your database credentials from wp-config.php. If permissions are too restrictive, WordPress itself can't function properly because it can't write to the uploads directory, update plugins, or modify configuration files. Getting the balance right is essential, and thankfully, the correct settings are well-documented and rarely change. This guide will give you the exact numbers for every WordPress file and directory, plus three different methods to check and fix them.

What Are File Permissions? (The 30-Second Explanation)

Every file and directory on a Linux server (which is where the vast majority of WordPress sites live) has three sets of permissions that control access for three categories of users. The owner is the user account that created or owns the file. The group is a set of users who share access to the file. And public (also called "others" or "world") is everyone else — any process on the server, including web visitors and malicious scripts. For each category, there are three types of access: read (view the file contents), write (modify the file), and execute (run the file as a program, or for directories, access the contents).

These permissions are represented as a three-digit number where each digit ranges from 0 to 7. The first digit is the owner's permissions, the second is the group's, and the third is public's. Each digit is calculated by adding: 4 for read, 2 for write, and 1 for execute. So 755 means the owner can read+write+execute (4+2+1=7), while the group and public can only read+execute (4+0+1=5). And 644 means the owner can read+write (4+2=6), while group and public can only read (4+0+0=4). If you remember just these two numbers — 755 for directories and 644 for files — you've got the fundamentals covered for 95% of WordPress setups.

Correct WordPress File Permissions

After years of working with WordPress across every hosting environment imaginable, here are the exact permissions I set on every site. These follow WordPress.org's official recommendations and work correctly on all major hosts. I've documented these in a reference table because I know from experience that you'll want to bookmark this page and come back to it.

A few notes on these settings. The wp-config.php permission of 440 is more restrictive than the default 644, and that's intentional. This file contains your database username, password, and authentication keys — it's the most sensitive file in your entire WordPress installation. Setting it to 440 (or 400 for even tighter security) means it can be read but not modified through the web server. On some hosting environments, you might need 444 instead of 440 if the web server process runs as a different user than the file owner. If WordPress complains about not being able to read wp-config.php after setting it to 400, try 440 instead. Never leave it at 644 if you can avoid it — that's leaving your database credentials readable by any process on the server.

The wp-content/uploads directory is set to 755 like all other directories. Some guides recommend 775 or even 777 for uploads, but this is almost never necessary on a properly configured server. If your uploads are failing with 755, the issue is likely file ownership (the web server process doesn't own the directory), not permissions. Fix the ownership instead of loosening the permissions. Your hosting provider can help with this if needed.

How to Check and Fix File Permissions

Method 1: Via FTP/SFTP Client (FileZilla)

This is the most accessible method and the one I recommend for most site owners. Download and install FileZilla (free, open-source, works on Windows, Mac, and Linux) and connect to your server using the SFTP credentials from your hosting provider. Always use SFTP (not plain FTP) — SFTP encrypts the connection, while plain FTP sends your password in cleartext. Once connected, navigate to your WordPress root directory (usually /public_html/ or /var/www/html/).

To check permissions on any file or directory, right-click it and select File Permissions (or File Attributes depending on your FileZilla version). You'll see the current numeric permission value and checkboxes for each permission type. To fix a single file, simply type the correct value (e.g., 644) in the numeric field and click OK. To fix permissions on a directory and everything inside it, right-click the directory, select File Permissions, enter the value, and check "Recurse into subdirectories." When recursing, select "Apply to files only" when setting 644 and "Apply to directories only" when setting 755. This is important — you don't want to set 644 on directories (that would remove the execute permission needed to access directory contents) or 755 on files (that would make them executable, which is unnecessary and a security risk for PHP files).

Pro tip: After setting bulk permissions, go back and manually set wp-config.php to 440 or 400. The bulk operation would have set it to 644 along with all other files. This single file deserves special treatment because of the sensitive credentials it contains.

Method 2: Via SSH Command Line

If you have SSH access to your server (most VPS and managed hosting plans include this), the command line is the fastest way to fix permissions across your entire WordPress installation. Connect via SSH and navigate to your WordPress root directory, then run these two commands:

find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;

The first command finds all directories (-type d) and sets them to 755. The second finds all files (-type f) and sets them to 644. Together, they correct every permission in your WordPress installation in seconds. After running these two commands, secure wp-config.php separately:

chmod 440 wp-config.php

That's it — three commands and your entire WordPress installation has correct permissions. This is the method I use on every site I manage because it's fast, reliable, and leaves no room for error. If you're not comfortable with SSH, that's perfectly fine — the FileZilla method achieves exactly the same result, it just takes a bit longer. For a broader look at securing your WordPress installation, these permission fixes are one of many recommendations in my complete WordPress security guide.

Method 3: Via Hosting File Manager

Most hosting control panels (cPanel, Plesk, DirectAdmin) include a web-based file manager that lets you view and change file permissions without installing any software. In cPanel, go to Files → File Manager, navigate to your WordPress root directory, right-click any file or folder, and select Change Permissions. You'll see a dialog with checkboxes or a numeric input field. The downside of hosting file managers is that they usually only let you change permissions on individual files or directories — there's no "apply recursively to all files" option in most implementations. This makes them impractical for fixing an entire WordPress installation, but they're convenient for quick checks or adjusting a single file like wp-config.php.

If your hosting provider offers WP-CLI access (many managed WordPress hosts do), you can also use the wp file permissions commands through the hosting dashboard's terminal feature. But honestly, if you have terminal access, you might as well use the SSH method above — it's faster and gives you more control.

Common Permission Mistakes (and Why They're Dangerous)

777 is never okay. I cannot stress this enough. Setting a file or directory to 777 means everyone — every user, every process, every script on the server — has full read, write, and execute access. On shared hosting, this means other users on the same server can read and modify your files. Even on a VPS where you're the only user, 777 means any compromised script or plugin can modify any file without restriction. I've seen hosting forums where the "solution" to upload or plugin installation problems is "just chmod 777 everything" — this is catastrophic security advice. If a plugin requires 777 to function, find a different plugin. If a directory needs 777 for uploads to work, the real problem is file ownership, not permissions.

Leaving wp-config.php at 644 is a very common oversight. Yes, 644 is the correct default for WordPress files, but wp-config.php isn't a normal file — it contains your database host, username, password, and secret authentication keys. With 644 permissions, any PHP script on your server can read this file. In a malware scenario, one of the first things an attacker's script does is read wp-config.php to obtain your database credentials, which they then use to inject malicious code directly into your database. Setting it to 440 or 400 significantly limits who can read this file. Some security plugins like Wordfence and Sucuri will flag this in their security audits if it's set too permissively.

Making PHP files executable (7xx) is unnecessary and creates risk. PHP files don't need the execute bit set to run — they're interpreted by the PHP engine, not executed directly by the operating system. When you set files to 755 instead of 644, you're adding execute permission for no functional benefit while creating a larger attack surface. If an attacker manages to upload a malicious PHP file, execute permission makes it easier to leverage. Always use 644 for files and 755 only for directories. This is a fundamental aspect of what I cover in my WordPress security hardening guide.

Disable File Editing from the WordPress Dashboard

WordPress includes a built-in theme and plugin editor accessible at Appearance → Theme File Editor and Plugins → Plugin File Editor. This editor lets anyone with admin access modify PHP files directly from the browser. While convenient for quick tweaks, it's a massive security risk: if an attacker gains admin access to your WordPress dashboard (through a stolen password, a compromised plugin, or a session hijacking attack), they can immediately inject malicious code into your theme or plugin files without needing FTP or SSH access. This is one of the most commonly exploited post-authentication vulnerabilities in WordPress.

Disabling this editor is a one-line addition to wp-config.php. Open the file via SFTP or SSH and add this line anywhere above the /* That's all, stop editing! */ comment:

define('DISALLOW_FILE_EDIT', true);

This removes the Theme Editor and Plugin Editor menu items entirely. If you ever need to edit a file, you can do it properly via SFTP or SSH, which provides a natural barrier that prevents quick-and-dirty modifications from the dashboard. I add this line to every WordPress site I set up, no exceptions. While you're editing wp-config.php, you might also consider adding define('DISALLOW_FILE_MODS', true); which goes further and prevents plugin and theme installations/updates from the dashboard entirely. This is more restrictive and requires you to manage all updates via FTP/SSH or WP-CLI, so it's best suited for production sites where stability is paramount and changes go through a proper deployment process. For more tips on hardening your WordPress installation beyond file permissions, check out my complete security guide.

Pro tip: If you're working with a team and need to track who changed what, DISALLOW_FILE_EDIT also serves as a governance control. When all file changes must go through SFTP or Git, you have a clear audit trail of who modified which files and when. Combined with proper automated backups, this gives you both accountability and the ability to roll back any problematic change.

Frequently Asked Questions

Will wrong file permissions break my WordPress site?

It depends on which direction they're wrong. Permissions that are too loose (like 777) won't break functionality but create serious security vulnerabilities. Permissions that are too tight (like 400 on directories or 000 on files) will absolutely break things — WordPress won't be able to read files, serve pages, accept uploads, or install updates. The most common symptom of overly tight permissions is "white screen of death" or "permission denied" errors when uploading media, installing plugins, or updating WordPress. If this happens, use the SSH commands or FileZilla method above to reset to the standard 755/644 configuration and things should work immediately.

Do I need to change file permissions after every WordPress update?

No. WordPress updates preserve existing file permissions by default. When WordPress downloads and installs an update, the new files inherit the permissions of the directory they're placed in, which should already be correct. The only time you might need to recheck permissions is if you migrate to a new server, restore from a backup (some backup tools don't preserve permissions), or if your hosting provider changes their server configuration. I recommend running a quick permission check every few months as part of your regular site maintenance, or whenever something feels "off" with uploads or updates not working correctly.

My hosting provider says I need 777 for uploads to work. Is that safe?

No, and I'd seriously question that advice. No modern hosting environment should require 777 for WordPress uploads to function. The real issue is almost always file ownership: the web server process (usually running as www-data or apache) needs to own the uploads directory, or at least be in the same group as the file owner. Ask your hosting provider to fix the ownership instead of loosening permissions. The correct command is something like chown -R www-data:www-data wp-content/uploads (the exact username depends on your server configuration). If your host insists that 777 is necessary and won't fix the ownership, that's a red flag about their server configuration, and you might want to consider switching to a better host.