WordPress File Permissions Best Practices: A Practical Guide for Secure Sites

Introduction

File permissions in WordPress are something most site owners ignore until something breaks. You get a white screen, can’t upload media, or a plugin fails to update. If you’ve been there, you already know the frustration.

This article is for anyone who manages a WordPress site — business owners maintaining their own site, developers who’ve inherited a messy install, or someone transitioning from clicking buttons in a dashboard to actually understanding what happens on the server. I’m going to explain file permissions in a way that’s practical and immediately useful.

Here’s the truth: messing up permissions is one of the fastest ways to either break your site or open a security hole. Get them right, and you’ll have fewer late-night emergencies and a more stable site.

Understanding Default WordPress File Permissions

Every file and directory on your server has a set of permissions that determine who can read, write, or execute it. WordPress works out of the box with a standard scheme: files set to 644 and directories set to 755.

These aren’t random numbers. Each digit maps to a specific user category: the file owner, the group, and everyone else. The number itself is the sum of read (4), write (2), and execute (1) permissions.

• 644 for files means the owner can read and write. Everyone else can only read. That’s enough for WordPress to serve your content without letting the world modify files.
• 755 for directories means the owner can read, write, and execute (enter). Everyone else can read and execute — enough to browse the directory structure but not modify it.

Why these defaults? They balance functionality with security. The web server needs read access to serve files, but you don’t want random users or processes making changes. Stick to this scheme unless you have a specific reason to deviate.

The Most Common Permission Mistakes That Break Your Site

I’ve seen the same errors repeat across dozens of sites. Here are the ones that cause the most damage.

Setting everything to 777. This is the panic move. A plugin fails, you read a forum that says “just set permissions to 777,” and suddenly your entire site is world-writable. That means any script on the server — including malicious ones — can modify your files. Do not do this.

Using 755 on files. Files don’t need execute permissions. Setting a PHP file to 755 means the owner can execute it, which is unnecessary and wastes a security layer. Files should be 644. Directories should be 755. It’s that simple.

Mixing owner and group settings incorrectly. On shared hosting, your user account and the web server user are often different. If your files are owned by the wrong user, even correct permissions can cause write failures. This is especially common after migrating a site.

The immediate symptoms are obvious: a white screen of death, inability to install plugins, media uploads failing, or error messages about file access. You can often recover quickly once you understand what happened.

How to Check Current File Permissions on Your Server

You have a few options here depending on your comfort level with the command line.

cPanel File Manager: Log in, navigate to your WordPress directory, and right-click any file or folder. Select “Change Permissions” to see the current numeric value. You can also bulk-select files to check multiple at once.

FTP client (FileZilla): Connect to your server, browse to your WordPress install, and right-click a file. Choose “File Permissions.” FileZilla shows the numeric value and lets you change it in place. The directory view also highlights permission differences with color coding. If you don’t have an FTP client yet, an FTP client is worth having for making quick permission adjustments.

WP-CLI (if you have command-line access): Run this to see permissions for all files:

find /path/to/wordpress -type f -printf "%m %p\n" | head -20

That pipes the first 20 lines. Remove the head part to see everything, but be prepared for a long list on larger sites.

Whichever method you use, check your wp-content directory and wp-config.php first. Those are where most permission-related issues show up.

Recommended Permission Scheme for a Secure WordPress Site

Here’s the scheme I recommend for most production sites. It’s conservative but functional.

File/Directory	Permission	Rationale
All files	644	Owner writes, everyone reads.
All directories	755	Owner writes, everyone reads and executes.
wp-config.php	600	Only owner reads and writes. No one else sees credentials.
.htaccess	644	Owner writes, everyone reads. Apache needs to read it.
wp-content/uploads	755	Owner writes, everyone reads and executes.
wp-content/plugins	755	Owner writes, everyone reads and executes.
wp-content/themes	755	Owner writes, everyone reads and executes.

You might wonder why wp-config.php is set to 600 instead of 644. The reason is simple: that file contains your database credentials and secret keys. Making it world-readable is an unnecessary risk. Some hosts require 640 or 644 for their web server to read it, but 600 is the goal if your server setup allows it.

Similarly, 640 might seem more restrictive than 644, but it can cause issues if the web server runs under a different group than expected. Test 600 and 640 on your specific host before assuming they work.

When to Use 777 Permissions (and When to Absolutely Not)

I’ll be direct: you almost never need 777. The rare exceptions are specific and temporary.

Legacy plugins: A few older plugins or poorly coded themes require write access to directories that shouldn’t need it. If you’re stuck with one, you might need 777 on a specific folder — but only that folder, not the entire site. Upgrade or replace that plugin as soon as possible.

Temporary debugging: If you’re troubleshooting a write issue and need to test whether permissions are the problem, you might temporarily set something to 777 to isolate the cause. Then immediately revert it. Leaving 777 in place is not a solution.

Automatic updates: Some hosts require 777 on the wp-content directory for WordPress to apply automatic updates. If that’s your host’s requirement, you’re better off either finding a better host or disabling automatic updates entirely.

In every other case, 777 is a security vulnerability waiting to be exploited. It’s the digital equivalent of leaving your front door wide open with a sign that says “come on in.”

Shared Hosting vs. VPS vs. Managed WordPress: Permission Differences

The hosting environment changes how permissions work in practice.

Shared hosting: You’re one of many users on a single server. Your user account and the web server user (often nobody or www-data) are different. This creates ownership conflicts — your files might be owned by your user, but the web server needs to read them. Permissions like 755 on directories and 644 on files handle this well, but misconfigured ownership can break things.

VPS: You have full control. You can set the web server user and your user to be in the same group, which simplifies permissions. You also have sudo access, so you can fix ownership issues without contacting support. The downside is that you’re responsible for everything — one wrong command can lock you out entirely.

Managed WordPress hosts: Companies like WP Engine, Flywheel, and Kinsta abstract permissions away. You don’t need to worry about them because their infrastructure handles file access differently. But here’s the catch: if you’re migrating a site from a standard host, you might still need to check permissions during the move. If something goes wrong, support can fix it quickly.

For most business owners, a managed host removes the headache completely. For developers or budget-conscious operators, a VPS with proper ownership and permissions is a solid choice. Avoid shared hosting if permissions are a frequent source of trouble for you.

How to Fix Broken Permissions After a Plugin or Theme Update

Updates can reset permissions or break file access. Here’s how to recover.

First, identify the problem. Check your debug log (/wp-content/debug.log if enabled). Look for failed to open stream or Permission denied errors. If the error mentions a specific file path, that’s your starting point.

Re-apply default permissions recursively. From the command line, run these commands:

find /path/to/wordpress -type f -exec chmod 644 {} \;
find /path/to/wordpress -type d -exec chmod 755 {} \;

That sets all files to 644 and directories to 755. It’s a safe reset. Then manually set wp-config.php back to 600.

Check ownership after the reset. If the update changed the file owner (common with malicious plugins), you’ll need chown to fix it. Run chown -R user:group /path/to/wordpress where user:group matches your web server setup.

In most cases, that’s enough. If the problem persists, the plugin or theme itself may be the culprit, not permissions. Try disabling it and testing.

Automating Permission Management with WP-CLI and Scripts

If you manage multiple sites or just want to save time, automate the process.

WP-CLI single command: You can check and reset permissions with one line:

wp core update-db and wp core verify-checksums will check core integrity. For permissions, create an alias:

alias fixperms='find . -type f -exec chmod 644 {} \; && find . -type d -exec chmod 755 {} \; && chmod 600 wp-config.php'

Then just type fixperms inside any WordPress directory.

Bash script for regular checks: Create a file called check-permissions.sh with this content:

#!/bin/bash
echo "Checking files..."
find /var/www/html -type f -not -perm 644 -exec echo "Incorrect: {}" \;
echo "Checking directories..."
find /var/www/html -type d -not -perm 755 -exec echo "Incorrect: {}" \;

Set it to run weekly via cron. You’ll get an email listing anything out of place.

For multi-site setups: Loop through each site’s directory in a script. This scales directly with the number of sites you manage and saves hours of manual checking.

The Role of Ownership: Why User and Group Matter Just as Much

Permissions are only half the equation. Ownership is the other half, and it’s often the hidden cause of permission failures.

On a typical server, the web server runs as a specific user (www-data on Apache/Nginx setups) and your files are owned by your FTP user. If the web server user is not in your user’s group, the “group” and “others” permissions kick in. That’s why 755 directories and 644 files work — they allow the web server to read and traverse without being the owner.

Common misconfiguration: After restoring a backup or migrating a site, the owner might change to root or another user. Your files are now owned by someone the web server can’t identify, and even correct permissions won’t help because the web server isn’t the owner and isn’t in the correct group.

Fix this with chown -R youruser:www-data /path/to/wordpress (adjust the group name based on your server). On a VPS with PHP-FPM, the ownership might be youruser:youruser with the web server running as a separate user but your files still accessible via group permissions.

If you’re on shared hosting and cannot change ownership, contact support. They can adjust the group membership or user mapping so your files are accessible.

Five-Minute Security Audit: Quick Permission Checklist

Do this once a month. It takes five minutes and catches most permission-related issues before they cause problems.

• Check wp-config.php permissions. It should be 600. If it’s 644 or higher, anyone on the server can read it. Fix immediately.
• Confirm uploads directory is 755. Not 777. A world-writable uploads folder is a common entry point for malicious file uploads.
• Verify index.php is not writable by others. It should be 644. If anyone else can write to it, they can inject code.
• Check the entire wp-content directory. It should be 755 at the base, with files inside at 644. A single 777 file could be a warning sign.
• Review your .htaccess file. It should be 644. Apache needs to read it, but no one else should write to it.

For a deeper check, install a security plugin like Wordfence or iThemes Security. They scan for permission issues and alert you automatically. That’s a good safety net, but the manual check remains valuable because you’ll catch things plugins sometimes miss.

Mistakes I’ve Made and What They Taught Me About Permissions

I’ll share a few lessons learned the hard way.

Lesson one: Early on, a plugin wasn’t working. A forum post said “just chmod 777 the whole site.” I did it. The plugin worked. Two days later, my site was defaced. The attacker found a vulnerable script that could write to 777 directories and injected a payload. A quick fix turned into a real headache.

Lesson two: After moving a site between servers, I couldn’t upload media. Every attempt failed. Permissions looked fine. I spent hours debugging. The issue was ownership: files were owned by root from the backup process. The web server couldn’t write because it wasn’t the owner. One chown command fixed it. That taught me to check ownership before touching permissions.

Lesson three: I locked myself out of a site by setting wp-content to 600. Thought I was being extra secure. What I actually did was make the web server unable to read plugin files, which broke the admin dashboard. Had to use FTP to change it back. The default 755 exists for a reason.

These mistakes are common. If you’ve made them, you’re in good company. The key is to learn from them and build better habits.

Final Recommendations for Long-Term Permission Health

File permissions aren’t a one-and-done thing. They change during updates, migrations, and plugin installations. The goal is to have a system that catches issues early.

Here’s what I’d suggest:

• Stick to the default scheme: 644 for files, 755 for directories. Deviate only with a clear reason and a plan to revert.
• Run a permission check after every major update — plugin, theme, or core. It takes two minutes with a script.
• Use a security plugin as a safety net. A good WordPress security plugin like Sucuri or MalCare offers file monitoring that alerts you to unexpected permission changes.
• Schedule a quarterly audit. Pick a Sunday morning, run through the checklist, and forget about it for another three months.

If you’re still unsure, start with the defaults and test. Most hosts handle this well. For those who don’t, the steps in this article give you a clear path forward. Permissions are a foundation — get them right, and everything else stands on solid ground.