WordPress Permissions 101: Recommended File and Folder Settings

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.

TL;DR: 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:

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:

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/wordpress

For a specific file:

stat /path/to/wordpress/wp-config.php

Replace /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:

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.

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.

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.php

Replace /path/to/wordpress with your actual path. Do not use:

chmod -R 777 /path/to/wordpress

Do 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:

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:

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

WordPress permissions are not mysterious once you understand the pattern. The safe path is: baseline, caveat, backup, smallest change, test.

FAQs