Your site won't load, the browser shows 403 Forbidden, or WordPress says Could not create directory when uploading a theme. You open File Manager, right-click the folder, set it to 777, and the problem goes away. Until next week when your hosting provider emails you saying an unknown PHP file was executed inside wp-content/uploads. This article is about that gap between "it works" and "it's correct."
What file permissions mean and why they're written as numbers
Linux defines three groups for every file: owner (user), group, and others. Each group has three bits: read (r=4), write (w=2), and execute (x=1). The number you write in chmod is the sum of these bits. So 644 means the owner can read and write, the group can only read, and others can only read. 755 means the owner can do everything, and everyone else can only read and enter the folder.
A point many people don't know: the meaning of x differs on a file versus a folder. On a file it means "can be executed." On a folder it means "you can go inside it and see the names of its files." If a folder is 644, even if the file inside it is 644 and perfectly readable, the web server can't reach that file. The resulting error is also misleading: 403 Forbidden on a file that itself has no problem at all.
The correct values for file and folder permissions
For the vast majority of PHP sites on shared hosting, these two numbers are enough:
- Files:
644 - Folders:
755
That's it. If file ownership is correct, these two numbers make everything work. The command to run it all at once via SSH:
find /home/USER/public_html -type d -exec chmod 755 {} \;
find /home/USER/public_html -type f -exec chmod 644 {} \;The order matters: folders first, then files. If you do it the other way around and a folder is created later, the result is the same, but running the command on a large tree takes a few seconds and it's better to do it once and do it right.
Exceptions that actually exist
There are three places where you usually need to deviate from the rule above. First, the wp-config.php file in WordPress, which you can set to 600 or 640; no one but the owner should be able to read it. Second, folders where a script needs to create files inside them, such as wp-content/uploads or plugin cache folders; these often work with 755, but if PHP runs under a different ownership, 775 becomes necessary. Third, executable files like wp-cron.php, which some environments call with 755.
And a warning: 775 only makes sense when the owner and group are set correctly. If file ownership is nobody:nobody and you set 775, you've effectively given every user on the server write permission. This is where people make the mistake: they change the number, not the ownership.
Why 777 isn't a solution, even when it works
777 means any user on that server, from any other site hosted on the same machine, has permission to write to and execute your files. On shared hosting, this means a neighboring site that has itself been hacked can place a PHP file inside your wp-content/uploads and execute it. You see no sign of it; your site works fine. Until the hosting provider's scanner or a suspicious outbound traffic report gives it away.
The second problem is more technical. Some hosts, due to suPHP or PHP-FPM settings, reject files with 777 permissions entirely, and instead of fixing the error, you get a 500 Internal Server Error. So 777 is neither secure nor does it always work. If you see a white screen after changing permissions, the error path is elsewhere; the guide to fixing the white screen in WordPress and PHP explains the correct order for checking logs.
The real sign of an ownership problem
If you still get a write error with 755 and 644, the problem is almost always ownership, not the number. Check with SSH:
ls -ln /home/USER/public_html/wp-content/uploads
id
ps aux | grep -E 'php-fpm|apache' | head -3If the file owner isn't the same user that PHP runs under, no number will solve the problem. The right fix is to correct the ownership:
chown -R USER:USER /home/USER/public_htmlOn shared hosting you usually don't have chown access and have to ask the panel or support ticket. On your own dedicated server you don't have this limitation, and that alone is reason enough for some teams to migrate away from shared hosting after a while.
Common errors and what you see in the log
| Symptom | Likely cause | Action |
|---|---|---|
403 Forbidden on a file | Parent folder lacks execute (x) permission | Set the folder to 755 |
Permission denied in PHP log | Incorrect ownership or read-only folder | Check ls -ln and fix ownership |
| Upload fails in WordPress | uploads isn't writable | 755 or 775 if needed |
500 Internal Server Error after chmod | 777 rejected by PHP handler | Revert to 644/755 |
| Plugin can't create files | Cache folder with wrong ownership | Delete the folder and let PHP recreate it |
A practical tip: before any bulk change, save the permissions output so you can revert if something breaks.
find /home/USER/public_html -printf '%m %p\n' > ~/perms-backup.txtWhen you should deviate from the 644/755 rule
If your site is on shared hosting and ownership is set correctly, keep 644 and 755 and don't set 777 for any reason. If you're on a VPS or dedicated server and run PHP-FPM under a dedicated user for the site, the same 644/755 is enough and more secure than anything else. The only case where 775 makes sense is when there's a shared group between the web server and the deploy user, and both need to write in the folder. Even then, 777 is the wrong choice.
For a test environment or admin panel, use web server authentication instead of opening up permissions; password-protecting a folder in hosting was written for exactly this scenario and is more secure than any change to chmod.
If your site has a lot of files and managing permissions manually has become time-consuming, the guide to creating and managing FTP accounts shows how to limit access from the account side, not the file side. And if you want to know what other limits apply to your hosting, the hosting resource limits reference explains each number separately.
Frequently asked questions
What are the correct permissions for WordPress files?
Files 644 and folders 755. These two numbers are enough for most WordPress installations on shared hosting and you don't need to change them. The only exceptions are wp-config.php at 600 or 640 and the upload and cache folders, which reach 775 if needed.
Why does the site work after 777 but the hosting provider warns me?
Because 777 gives every user on the server write and execute permission. Your site works, but if another site on the same server gets infected, an attacker can place a malicious file inside your folders and execute it. The hosting warning is usually sent after an automatic scan of exactly these files.
What's the difference between chmod and chown, and which should I use?
chmod changes permissions and chown changes ownership. If you get a write error and permissions are 644/755, the problem is ownership and you need to run chown. On shared hosting you usually don't have this access and have to ask support.
Is 755 secure for a folder?
Yes, provided ownership is correct. 755 means only the owner can write and everyone else can only read and enter the folder. The danger starts when ownership is given to the wrong user, such as nobody; then 755 is effectively open too.
Before any bulk change, save the permissions output once and then run the find command. If the site doesn't come up afterward, it's probably ownership, not the number. To start with, Linux hosting with correctly configured ownership is exactly what reduces this class of errors at the root.