Practical guides on websites, online stores, and getting found on Google — written for business owners, not developers.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
The exact WordPress file permissions to use: 644 for files, 755 for folders, and what to do differently for wp-config.php. No guesswork, no 777.
You're probably here for one of three reasons. WordPress is refusing to update because of a permissions error. A security scan flagged your file permissions. Or someone told you to run chmod 777 and it felt like the wrong answer.
That instinct is correct. 777 is never the fix.
WordPress file permissions aren't complicated once you know the actual numbers and where they apply. What most guides skip is why they matter beyond fixing an error message. We've gone through a hacked client site file by file, and the permissions on that server decided more than whether a plugin update worked.
This guide gives you the exact values to use, how to change them without breaking your site, and what actually happens when you get them wrong.
Every file and folder on your server answers the same three questions. Who owns it. Who else can touch it. And what "touch" is allowed to mean. WordPress encodes those answers into a three-digit number, one digit each for the owner, the group, and everyone else.
Each digit adds up three abilities. Read is worth 4, write is worth 2, execute is worth 1. So 644 means the owner can read and write while everyone else can only read. 755 means the owner can also execute, and so can everyone else, but only the owner can write.
Directories need execute permission just to be opened. Files never do, because WordPress hands a PHP file to PHP to run rather than the operating system executing it directly. That's the whole logic behind 644 for files and 755 for directories.
Get this wrong and you're not just risking an update error. Misconfigured permissions sit inside what OWASP classifies as Security Misconfiguration, one of the most common ways WordPress sites get broken into.
Here are the numbers to actually use. Not "it depends," just the values that work for the overwhelming majority of WordPress installs.
Item | Permission |
|---|---|
All files | 644 |
All directories | 755 |
wp-config.php | 440 or 400 |
.htaccess | 644 |
wp-content/uploads | 755 |
Anything not listed follows the same rule. 644 if it's a file, 755 if it's a directory.
wp-config.php gets tighter treatment because it holds your database password and security keys in plain text. 440 means only the owner can read it at all. Some hosts need 600 or 640 instead, depending on how their server processes are set up. If 440 breaks something, that's the reason, not a sign you got it wrong.
wp-content/uploads stays at 755 because media uploads need it writable. That's exactly why it deserves a closer look further down.
This is where people get stuck, and it's why they burn hours on a problem that was never about permissions at all.
Permissions decide what's allowed. Ownership decides who you are, as far as the server is concerned, and your permission number only means anything relative to the file's owner.
So if you've set 644 and 755 correctly and WordPress still can't upload an image or install an update, the numbers probably aren't the problem. The file is more likely owned by a different user than the one your FTP or SSH login connects as, and no permission value fixes that. Ask your host to change ownership rather than running another round of chmod.
If the right numbers aren't fixing it, stop adjusting permissions and check ownership instead.
Before you touch a single value, look at what you're already working with. Don't assume the defaults broke just because something else on the site did.
Three ways to check, depending on how you're already connected:
FTP client: most list permissions as a column next to each file, usually the three-digit number or the rwx string
cPanel File Manager: right-click any file or folder and look for Permissions
SSH: run ls -la in your WordPress root and read the string on the left of each line
Checking first tells you whether permissions are actually the problem, and gives you something to revert to. Back up before you change anything on a live site. That's what turns a mistake into a five-minute fix instead of a support ticket.
There are three ways to actually set these values.
Through a GUI (cPanel File Manager or an FTP client). Right-click the file or folder, look for Permissions or CHMOD, and enter the numeric value directly. Only tick "recurse into subdirectories" when every file inside genuinely needs the same value, which works for wp-content but not for wp-config.php sitting one level up.
SSH or command line. The fastest way to fix an entire site at once, and the method we use on client sites. From your WordPress root:
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 440 wp-config.phpDirectories, then files, then wp-config.php set separately because it needs a different number than everything around it.
Never run a single blanket chmod -R 755 or chmod -R 777 across the whole site. Directories and files need different values, and there's no version of "just use one number for everything" that ends well.
Everything above assumes you have FTP or SSH access and a server that lets you set these values yourself. On managed WordPress hosting, that assumption often doesn't hold.
Kinsta, WP Engine, Flywheel, and Pressable run their own file management layer. Some don't give you write access to change permissions directly. Others quietly reset them to their own defaults on the next deploy or sync, undoing whatever you just set.
If a permissions error shows up on one of these, don't fight the platform. Check the host's own documentation first, because their setup is often already correct on its own terms even when it doesn't match the numbers above. Open a support ticket if something still looks wrong rather than forcing it through FTP.
This is also exactly the kind of host-specific troubleshooting that gets handled quietly under a maintenance plan rather than something a site owner has to diagnose alone.
Most guides treat file permissions as something you fix so an error message goes away. That undersells what they actually do.
Permissions decide what a file is allowed to do once it lands on your server. This matters most on shared hosting, where "everyone else" isn't an abstraction. It can be another customer's compromised account on the same server, which is how one hacked site ends up infecting its neighbors.
In one incident we worked, the malicious file wasn't hidden inside a plugin or theme folder. It was sitting directly in wp-content/uploads, a folder meant for images and documents, not executable code. That site was hit through a fake Cloudflare verification page that walked visitors through pasting a command into Windows Terminal, a full incident we've written up separately.
Correct permissions on that folder don't stop a file from being placed there in the first place. Paired with one more step, they stop it from running even if it gets in. Block PHP execution inside wp-content/uploads entirely, with a small .htaccess rule scoped to that folder:
<Files *.php>
Require all denied
</Files>Permissions restrict who can write. This restricts what a written file is allowed to become. Use both.
Here's exactly how to check your own uploads folder for something similar, without installing another plugin.
A few ways people get this wrong even after reading the right numbers.
Over-restrict the uploads folder and image uploads start failing silently, which then gets "fixed" with 777 out of frustration, right back to the problem this article is trying to prevent.
Treating a permissions fix as the finish line is another. Correct permissions are baseline hygiene, not protection against someone who already has a way in. They limit damage. They don't replace a firewall, malware scanning, or keeping plugins updated.
And the one nearly everyone skips: not testing afterward. Upload an image. Check for a pending plugin update. Load the site logged out. If any of that breaks, check ownership before touching permissions again, because that's almost always the real cause.
644 for files, 755 for directories, wp-config.php locked down tighter than either. Check what you have before you change it, back up first, test afterward.
Permissions are one piece of a wider hardening pass, not the whole job. Pair this with locking down wp-config.php and .htaccess properly, and look at who can even reach your site in the first place.
If touching server files isn't something you want to do yourself, or you'd rather have someone confirm the site is locked down afterward, that's exactly what a security audit covers.
644 for all files, 755 for all directories, and 440 or 400 for wp-config.php specifically. Those three values cover a standard WordPress install on shared or VPS hosting.
440 or 400 in most cases. Some hosts require 600 or 640 instead, depending on how their server processes read the file. If the tightest value breaks something, that's your host's setup telling you which one it needs.
It means WordPress doesn't have write access to make the change directly, usually because the file owner and the user WordPress runs as don't match. It's an ownership issue more often than a permissions one.
No. 777 gives every user on the server full read, write, and execute access. It solves the error by removing the protection that caused it, which isn't a fix.
Rarely on their own. What loose permissions do is make it easier for something that already got in to spread, persist, or run. They're one layer, not the whole defense.
Usually not, and often you can't. Managed hosts frequently control this themselves and reset it on their own schedule. Check their documentation before changing anything through FTP.
Written by AppDeel Editorial Team
The AppDeel Editorial Team draws on designers, developers, SEO, security, growth marketing, social media and AI automation specialists who have worked with businesses for over ten years. Every article is researched thoroughly before publishing and reviewed by whichever specialist actually does that work. The team is led by Azizul Hakim, founder of AppDeel.
Read more posts by AppDeel Editorial Team →
OWASP updated its Top 10 for 2026. Here's what each risk actually means for a WordPress site, ranked by what causes real hacks, not theory.
19 real signs your WordPress site is hacked, grouped by who notices first: you, Google, or your host. Each comes with the 2-minute check to confirm it.
Block unwanted IPs, countries, and regions in WordPress the right way — .htaccess, nginx, plugins, and Cloudflare, with a decision table for each.
XSS lets hackers run malicious scripts on your WordPress site through comments, forms, or vulnerable plugins. Here's what it is and how to stop it.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.