Sometimes WordPress breaks in the least helpful way possible. You try to upload an image, update a plugin, save a permalink change, or open a page, and suddenly the site complains that a file is not writable or throws a 403 Forbidden error.
That is usually when people discover WordPress permissions. Then they find a forum thread that says 755, another that says 775, a security guide that says 400, and one terrifying comment that says to run chmod -R 777.
Do not do that last one. This guide will help you use the right permissions without breaking your site or weakening its security.
WordPress permissions decide who can read, write, or execute your site’s files and folders. For most sites, directories use 755, files use 644, and wp-config.php is usually stricter. Before changing permissions, take a full WordPress backup and check your host’s setup, because ownership and server configuration can affect the safest values.
The quick answer
Use these as a baseline, not as a command to blindly paste into a live site.
| WordPress item | Common recommended permission | What to know |
|---|---|---|
| Most directories | 755 | Lets the owner write; lets others read and enter folders. |
| Most files | 644 | Lets the owner write; lets others read. |
| wp-config.php | 640, 600, 440, or 400 where supported | This file contains database credentials and security keys. Stricter is better only if the site still works. |
.htaccess | Usually 644 on Apache | Some Nginx hosts do not use .htaccess at all. |
wp-content/uploads | Usually 755; sometimes 775 | Some hosts use group-write setups for uploads and cache files. |
| Cache or temporary folders | Host-dependent | These may need write access for the web server process. |
The important pattern is this: files and folders should be as restricted as they can be while still letting WordPress work.
That is the real rule. 755/644 is the common expression of it.
In a clean WordPress test environment we checked, the host used 775 for directories and 664 for files, with group ownership set so the web server could write where needed. That does not mean you should copy those values. It means real hosting environments can be different on purpose.
If your managed host installed WordPress and the site is working, do not overwrite its setup just because a generic article gives you a different number.
What Permissions Do
WordPress permissions are server file permissions. They control who can read, change, or run the files and folders that make up your site.
They affect ordinary site work:
- uploading images
- installing plugins and themes
- updating WordPress core
- writing cache files
- editing
.htaccessrules - reading PHP, CSS, JavaScript, and media files
They also affect security. A file that should only be readable may become writable. A folder that should accept images may become a place where malicious files can be planted. A configuration file that should be protected may be exposed too widely.
The visible problem is usually one error message. The hidden problem is the relationship between file mode, file owner, group owner, web server user, PHP handler, parent directories, and host policy.
That is why two people can both say “use the correct WordPress file permissions” and mean different things.
Should You Change Permissions?
Most site owners should not start here. If your site works, updates run normally, uploads work, and your host installed WordPress for you, leave the permissions alone. Change permissions only when there is a reason. Use this quick check:
| Situation | Should you change permissions? | Safer first move |
|---|---|---|
| Your site works normally | No | Leave host defaults alone. |
| You manually migrated or uploaded WordPress | Maybe | Compare current values with the baseline before changing anything. |
| Uploads fail with a write error | Maybe | Check wp-content/uploads permissions and ownership. |
| Plugin, theme, or core updates fail | Maybe | Check whether WordPress can write to the needed folder. |
| You ran a bad recursive command | Yes, carefully | Restore from backup or reset files and directories separately. |
| A security scan says permissions are loose | Maybe | Confirm the exact file, folder, and host model before hardening. |
| Someone tells you to use 777 | Almost never | Ask for the real write-access problem they are trying to solve. |
The common mistake is treating every mismatch from 755/644 as a problem. It is not. The scary permission is usually broad write access, especially world write access, not every host-specific difference.
Before you change anything, take a backup that includes files and the database. BlogVault is useful here because a permission change can break the site before you have time to calmly reverse it. A restorable backup turns a risky live edit into a recoverable maintenance task.
Understanding Permission Codes
The numbers look cryptic until you see the pattern. Each permission is built from three actions:
| Permission | Number | Meaning for files | Meaning for directories |
|---|---|---|---|
| Read | 4 | Open or read the file | List folder contents |
| Write | 2 | Change the file | Add, remove, or rename files in the folder |
| Execute | 1 | Run the file as a program or script | Enter or pass through the folder |
The digits are added together. So:
7means read + write + execute (4+2+1)6means read + write (4+2)5means read + execute (4+1)4means read only
A full permission number has three digits:
| Digit position | Applies to |
|---|---|
| First digit | Owner or user |
| Second digit | Group |
| Third digit | World, public, or everyone else |
| Permissions | Owner can | Group can | World can |
| 755 | Read, write, execute | Read, execute | Read, execute |
| 644 | Read, write | Read | Read |
Directories usually need execute permission because “execute” on a directory means people and processes can enter or traverse it. That is why folders commonly use 755 while files commonly use 644.
Plain English version: files usually need to be readable; folders need to be enterable; only the right owner or trusted group should be able to write. If you are checking those owner and group values from the command line, use WordPress SSH access carefully.
Permissions vs User Roles
Filesystem permissions control files and folders on the server. WordPress user roles control what a logged-in user can do inside wp-admin.
| If you mean… | You are dealing with… | Examples |
|---|---|---|
| Who can edit posts, install plugins, or manage users | WordPress roles and capabilities | Administrator, Editor, Author, Contributor, Subscriber |
| Who can read, write, or execute server files | Filesystem permissions | owner, group, world; 755, 644, 640 |
Changing wp-config.php to 640 will not stop an Editor from editing posts. Changing someone from Editor to Subscriber will not fix a Could not create directory upload error.
They are different systems. Solve the right problem. On multisite networks, review WordPress multisite roles separately before assuming a dashboard permission issue is filesystem-related.
Recommended permissions
This is the practical reference section. Start with the common baseline, then adjust only where your host requires it.
| File or folder | Common baseline | Host-specific exception | Why it matters |
|---|---|---|---|
WordPress root, such as public_html | 755 | Some hosts use 750, 775, or setgid folders | The server must be able to reach the site files. |
wp-admin/ | 755 | Managed hosts may use group-write models | WordPress admin files need to be readable and traversable. |
wp-includes/ | 755 | Rarely needs write access in normal use | Core files should not be broadly writable. |
wp-content/ | 755 | 775 may be valid when group write is required | Plugins, themes, uploads, cache, and upgrades live here. |
wp-content/uploads/ | 755 | 775 on some hosts | WordPress must be able to add media files. |
wp-content/plugins/ | 755 | Temporary write access may be needed for updates | Too-loose permissions make plugin files easier to alter. |
wp-content/themes/ | 755 | Temporary write access may be needed for updates | Theme files should not be casually writable. |
| Most PHP, CSS, JS, and image files | 644 | 664 can be valid in trusted group setups | Files need to be readable; most should not be writable by everyone. |
index.php | 644 | Host-dependent | The server must read it to load WordPress. |
wp-config.php | 640, 600, 440, or 400 if supported | Some hosts require 644 or group-readable settings | It contains database credentials and salts. Protect it carefully. |
.htaccess | 644 | Stricter may be okay; Apache-only; Nginx may not use it | WordPress and plugins may need to update rewrite rules. |
xmlrpc.php | 644 | Do not use permissions as your only XML-RPC security control | Some sites need it; some restrict access by server rules instead. |
The table hides one important thing: ownership can matter more than the number.
If the files are owned by the wrong user, WordPress may still be unable to write even when the mode looks permissive. FTP/SFTP can usually change file modes. It usually cannot fix ownership. SSH or host support is often needed for that.
Do not run random chown commands from a forum unless you know your host’s user model. Making everything owned by the web server can solve one update error and create a worse security model.
This is the part generic advice often skips. chmod answers “who can do what?” Ownership answers “who is this file actually assigned to?” WordPress needs both answers to line up with the way your host runs PHP.
Check Current Permissions
Check before you change. Write down the current values too, especially if the site is mostly working.
Check permissions in cPanel or your hosting file manager:
Open File Manager and go to your WordPress installation folder. This is often public_html, but it may be a domain-specific folder on some hosts. Look for a permissions column, properties panel, or “Change Permissions” option. Most file managers show values like 0755 or 0644. The leading zero is normal; people usually say 755 and 644.
Turn on hidden files if you need to see .htaccess.
Check permissions in FTP or SFTP:
Connect with an FTP/SFTP client and browse to your WordPress folder. Right-click a file or folder and look for “File permissions,” “Info,” or “Properties.” FTP/SFTP is fine for simple mode changes. It is not enough when ownership is the real problem.
If you keep changing a folder to 755 and WordPress still cannot write to it, stop repeating the same edit. You may be looking at an owner/group issue.
Check permissions with SSH:
SSH access gives the clearest view if you are comfortable with the command line. Use:
ls -la /path/to/wordpressFor a specific file:
stat /path/to/wordpress/wp-config.phpReplace /path/to/wordpress with your real WordPress path. Do not paste example paths into production and hope the server understands your intent. It will not.
Change WordPress Permissions Safely
The safest permission change is small, reversible, and verified.
Do this in order:
- Take a full backup of files and database.
- Check current permissions and ownership.
- Change only the file or folder related to the problem.
- Test the site. Escalate to your host if ownership or server rules are involved.
If the issue is urgent and your site is already broken, restore a known-good backup before stacking more changes on top of a bad state. This is where a tool like BlogVault earns its keep: you need a clean restore point, not another guess.
If the change is risky but not urgent, test it in a WordPress staging environment first.
After any permission change, test more than the homepage. Check wp-admin, upload a small image, update or reinstall a low-risk plugin if that was the original problem, and reload a page that uses CSS and images. A permission mistake can leave the front page looking fine while uploads or assets are still broken.
1) Via cPanel or File Manager
Use this for simple edits when you know which file or folder needs a change.
- Open your hosting File Manager.
- Go to the WordPress installation folder.
- Select the file or folder.
- Choose “Permissions,” “Change Permissions,” or “Properties.”
- Set the value, such as
755for a directory or644for a file. - Save the change.
This is the least intimidating method for many site owners. The tradeoff is that it can be slow if you need to repair many files.
2) Via FTP or SFTP
Use this when your host does not provide a good file manager or when you already manage files with SFTP.
- Connect to the site with your FTP/SFTP client.
- Browse to the WordPress folder.
- Right-click the target file or folder.
- Open the permissions dialog.
- Enter the numeric value.
- Apply the change.
- Test uploads, updates, or the page that failed.
Be careful with recursive changes. If your FTP client offers “apply to all files and folders,” make sure it lets you set different values for files and directories. Files and folders should not always receive the same mode.
3) Via SSH and chmod
SSH is efficient. It is also where people break entire sites in one line.
If you need to reset a WordPress install to the common baseline, separate directories from files:
find /path/to/wordpress -type d -exec chmod 755 {} \;
find /path/to/wordpress -type f -exec chmod 644 {} \;Then set wp-config.php more strictly only if your host supports it:
chmod 640 /path/to/wordpress/wp-config.phpReplace /path/to/wordpress with your actual path. Do not use:
chmod -R 777 /path/to/wordpressDo not use one recursive permission for everything unless you understand the consequence. A blanket recursive command is fast in the same way a chainsaw is fast.
4) Via a Security or Maintenance Plugin
Some WordPress security plugins can detect risky permissions or suggest fixes. That can be useful for visibility.
But a plugin is still running inside the same site and host environment. It may not understand every ownership model, server rule, or managed-host exception. Treat plugin suggestions as a warning to investigate, not as permission to click every fix button without a backup.
Use plugins for checks. Use host support or SSH when ownership is involved.
The Problem with 777
777 means owner, group, and everyone else can read, write, and execute.
On a live WordPress site, that is almost never a good permanent setting. It can let any process with access to that path modify files. If an attacker finds another weakness, world-writable folders make the damage easier.
The usual reason people try 777 is frustration. Uploads are failing, updates are stuck, and someone says, “Just make it writable.”
That fixes the symptom by removing the lock from the door.
If a plugin, theme, or support thread asks for 777, treat it as temporary at most. Ask what specifically needs write access. Often the safer fix is:
- correct ownership
- group write on one specific folder, such as
775 - host support adjusting PHP/user configuration
- a temporary permission change that you reverse after the task
Never leave your WordPress installation on recursive 777.
Troubleshooting
Permission errors often look like other server problems. Use the symptom to choose the next safe step.
| Symptom | Likely cause | Safe next step |
|---|---|---|
| 403 Forbidden | File or parent folder is not readable/traversable; server rules, symlinks, or access controls may also be involved | Check directory traversal permissions first, then review server rules or ask the host. |
| Could not create directory | WordPress cannot write to wp-content, uploads, upgrade, plugin, or theme folders | Check the target folder’s mode and ownership. |
| Failed to open stream: Permission denied | PHP cannot read or write a specific path | Identify the exact path in the error before changing anything. |
| Media uploads fail | uploads is not writable, ownership is wrong, or a temp folder is missing | Check wp-content/uploads and ask the host about PHP temp configuration. |
| Plugin/theme/core updates fail | WordPress cannot write to update paths | Check wp-content, upgrade, plugin, and theme directories. |
| Missing CSS, images, or scripts | Files or parent folders are not readable | Check file permissions and parent directory execute permissions. |
| White screen after “hardening” | Permissions became too strict for PHP or required files | Revert the last change or restore your WordPress site from a backup. |
.htaccess changes do not save | File is not writable or host does not use .htaccess | On Apache, check .htaccess; on Nginx, check server configuration instead. |
| Theme/plugin editor says a file is not writable | Permission is too strict, ownership is wrong, or editing is intentionally disabled | Do not loosen permissions just to use the editor unless you understand why it was disabled. |
The fastest way to make troubleshooting worse is to change five things at once. Change one thing, test, and keep notes.
If the site broke after a recursive chmod or chown, stop experimenting on the broken copy. Restore from a clean backup or ask the host to reset ownership and modes based on their server model.
That last phrase matters. Your host knows whether your account runs PHP as your user, as a web server user, through a shared group, or through a managed container. A permission value that is safe in one model can be wrong in another.
Permissions Are Not the Whole Fix
Good WordPress permissions reduce risk. They do not make a vulnerable plugin safe, fix weak admin passwords, clean malware, or stop every bad request.
Think of permissions as one part of site hygiene:
- keep WordPress core, plugins, and themes updated
- remove abandoned plugins and themes
- use strong admin passwords and two-factor authentication where possible
- keep a backup you can restore
- monitor for malware and suspicious changes
- avoid editing live files without a rollback path
The practical security goal is not to chase the lowest number. It is to keep the site working while limiting who can change sensitive files.
That is less glamorous than a magic hardening trick. It is also how real WordPress maintenance works.
Next Steps
- If you came here because the site is working and you were just checking best practice, your next step is simple: leave working host-managed permissions alone and make sure you have a reliable backup.
- If you came here because uploads, updates, or a page are failing, start with the specific folder or file named in the error. Check permissions and ownership before changing anything.
- If you came here after a recursive command broke the site, restore first. Then reset directories and files separately. Do not try to fix a site-wide permission mistake with another site-wide guess.
WordPress permissions are not mysterious once you understand the pattern. The safe path is: baseline, caveat, backup, smallest change, test.
FAQs
What are the default WordPress permissions?
For most WordPress sites, directories are commonly 755 and files are commonly 644. Sensitive files such as wp-config.php may use stricter permissions like 640, 600, 440, or 400, depending on the host.
What does 755 mean in WordPress?
755 means the owner can read, write, and execute. The group and everyone else can read and execute. It is commonly used for WordPress directories because folders need execute permission to be opened or traversed.
What does 644 mean in WordPress?
644 means the owner can read and write. The group and everyone else can read only. It is commonly used for WordPress files because most files need to be readable but not publicly writable.
Should WordPress files be 644 or 755?
Most WordPress files should be 644. Most WordPress directories should be 755. Do not apply 755 to every file just because it is the recommended value for folders.
Why are my WordPress permissions different from 755/644?
Your host may use a different ownership model, group-write setup, PHP handler, or managed configuration. Different is not automatically wrong. If the site works and the permissions are not broadly writable, check with your host before changing them.
Shivani enjoys crafting guides that make every aspect of using WordPress simple and easy to follow. When she's not glued to her laptop, you can find her buried in a good book or occasionally, painting.
