--- title: "WordPress file permissions: what to set and what they mean" url: https://wpministry.co/blog/wordpress-file-permissions-guide/ description: "WordPress's guidance is 755 for folders, 644 for files and 440 or 400 for wp-config.php, with every file owned by your hosting account. Nothing should be 777." lang: en-US --- Skip to content # WordPress file permissions: what the numbers mean and what to set WordPress's own guidance is 755 for folders, 644 for files and 440 or 400 for wp-config.php, with every file owned by your hosting account. Nothing should be 777. Who owns the files matters as much as the numbers. By WP Ministry Published October 7, 2026 Tested on WordPress 7.1.4, PHP 8.3.36 ## In short - A permission is three digits, for the owner, the group and everyone else. Read is 4, write is 2, execute is 1. - WordPress's guidance is 755 for folders and 644 for files. Some hosts also support the tighter 750 and 640. - wp-config.php holds the database password. WordPress's guidance for it is 440 or 400. - Who owns the files decides whether WordPress can update itself or asks for FTP details. - Never use 777 or 666. On shared hosting they let other accounts on the server change your files. - With no shell access, ask the host to reset permissions and ownership. WordPress's own guidance is short: folders at 755, files at 644, and `wp-config.php` at 440 or 400. Every file belongs to your own hosting account, and nothing is ever 777. The numbers are half of it. The other half is who owns the files and which user on the server PHP runs as. That decides whether WordPress can save an upload or update a plugin, and it is where to look when 755 and 644 are in place and something still fails. ## How to read a permission A permission is three digits. The first is for the file's owner, the second for the file's group, the third for everyone else. Each digit is a sum: 4 to read, 2 to write, 1 to execute. | Digit | Allows | | --- | --- | | 7 | Read, write and execute (4 + 2 + 1) | | 6 | Read and write (4 + 2) | | 5 | Read and execute (4 + 1) | | 4 | Read only | | 0 | Nothing | So 755 lets the owner do everything, and lets the group and everyone else read and open but not change. 644 lets the owner read and write, and everyone else only read. The same thing is often shown as letters: `rwxr-xr-x` is 755 and `rw-r--r--` is 644, and a `d` in front marks a folder. In a four-digit mode such as 0755, the leading zero changes nothing. ### Why a folder needs execute On a file, execute means the file can be run as a program. On a folder the three permissions mean something else: - **Read** lets you list what is in the folder. - **Write** lets you create and remove files in it. - **Execute** lets you reach the files in it. A folder at 644 can be listed, but nothing inside it can be opened. That is why folders get 755 and files get 644, and why one number for both is wrong for one of them. ## Ownership is the other half The digits are read against a file's owner and group, so the same 755 means different things to WordPress depending on which user PHP runs as. WordPress's documentation describes two setups. - **PHP runs as your own account.** The documentation calls this the suexec approach and says many shared hosts use it. WordPress acts as the owner, so the first digit applies to it. It can write to a 755 folder, and uploads and updates work with nothing looser. - **PHP runs as a separate user.** The web server has a user of its own, often `www-data` or `nobody`. Apache sets it with its `User` directive, and PHP-FPM with the `user` setting of each pool. WordPress then counts as "group" or "everyone else". At 755 and 644 it can read everything and change nothing. In both, the documentation says the same about shared hosting: the files belong to your account, never to the web server's own user. ### Why WordPress asks for FTP details Before it installs or updates anything, WordPress writes a small temporary file to the site and compares that file's owner with the owner of WordPress's own files. If they match, it writes directly. If they differ, or it could not write the file at all, it falls back to FTP or SSH and shows a form headed "Connection Information", which begins "To perform the requested action, WordPress needs to access your web server." The form is not a fault. It says that PHP is not the owner of the files. The comparison is about owners, not modes, so 777 does not make it go away. What to do depends on the hosting: - **On shared or managed hosting,** ask the host whether the site's files all belong to your account and whether PHP runs as it. Changing who owns a file is a job for the host. - **On a server you administer,** correct the ownership as the administrator with `chown -R`, giving the owner and group your setup expects. Do not set `FS_METHOD` to `direct` in `wp-config.php` to silence the form. WordPress's documentation says the direct method is chosen automatically when it is appropriate, and that forcing it opens security issues on poorly configured hosts. ## The modes WordPress recommends | What | Mode | Where the documentation gives a choice | | --- | --- | --- | | Folders | 755 | 750 on hosting where PHP runs as your account | | Files | 644 | 640 on the same kind of hosting | | `wp-config.php` | 440 or 400 | Whichever the host's setup can read | | `.htaccess` | 644 | | The tighter value in each pair takes away everyone else's access. It works only where the web server reaches the files as their owner or through their group: Apache has to read every file it serves and enter every folder on the way to it. If pages, images or stylesheets return 403 after you tighten, go back to 755 and 644. The documentation allows one looser case. Where WordPress runs as a different user that shares a group with the owner, what WordPress has to write can be group-writable: 775 for folders, 664 for files. That is for a server whose users you know. On shared hosting, it says the web server's user should neither own the files nor be in that group. ## How to see the current modes - **In the dashboard.** Go to Tools, then Site Health, then the Info tab, and open "Filesystem Permissions". It lists the main WordPress directory and the `wp-content`, uploads, plugins and themes directories, each as "Writable" or "Not writable". It shows whether WordPress can write, not whether the modes are safe: a site at 777 is writable everywhere. - **In an SFTP program or the host's file manager.** The file list has a permissions column. WordPress's documentation shows it in FileZilla: right-click a file, select "File Permissions", and the number is under "Numeric value". Files whose names begin with a dot, such as `.htaccess`, stay hidden until you turn on the option to show hidden files. - **Over SSH.** Run these from the site's main folder. bash ``` ls -la stat -c '%a %U:%G %n' wp-config.php .htaccess ``` `ls -la` lists every entry, dot files included, with its mode as letters, then its owner and group. `stat` in this form, which is the GNU one found on Linux servers, prints the mode as digits, then the owner, the group and the name. text ``` drwxr-xr-x 5 example example 4096 Oct 7 09:12 wp-content -rw-r--r-- 1 example example 405 Oct 7 09:12 index.php -r--r----- 1 example example 3264 Oct 7 09:12 wp-config.php ``` To learn which setup you are on, upload an image in the dashboard and compare the owner of the new file under `wp-content/uploads` with the owner of `index.php`. If they are the same, PHP runs as the files' owner. ## Correct them in bulk over SSH 1. ### Step 1: Go to the WordPress folder and confirm where you are Change to the site's main folder first. `pwd` prints the folder you are in. All three names should come back. If `ls` reports that one does not exist, you are in the wrong folder. Stop here. bash Copy ``` pwd ls -d wp-admin wp-content wp-includes ``` 2. ### Step 2: Keep a record of how things are now This writes the mode, owner, group and path of every file and folder to a file in your home folder, outside the site. It is how you find out later what an item was. bash Copy ``` find . -exec stat -c '%a %U:%G %n' {} + > ~/permissions-before.txt ``` 3. ### Step 3: List what differs The first command lists every folder that is not 755, the second every file that is not 644. Neither changes anything. `wp-config.php` appears if it is already tighter, which is as it should be. If nothing is listed, the modes are right and the problem is ownership. bash Copy ``` find . -type d ! -perm 755 find . -type f ! -perm 644 ``` 4. ### Step 4: Set folders to 755 and files to 644 These are the commands WordPress's hardening guide gives, with `.` in place of the path. They print nothing when they work. Anything set differently on purpose is reset too, such as a script that has to be run as a program or a folder made group-writable. The record shows which items those were. If `chmod` refuses a file, that file belongs to another user. Only a file's owner or the server's administrator can change its mode, so this is a question for the host. bash Copy ``` find . -type d -exec chmod 755 {} \; find . -type f -exec chmod 644 {} \; ``` 5. ### Step 5: Tighten wp-config.php again The step before set it to 644 with everything else. If your record shows the host kept it at a tighter value of its own, use that value here. Reload the site. If it loads, leave the file as it is. If it does not, PHP cannot read the file at that mode: put it back with `chmod 644 wp-config.php`, or with the value in your record, and ask the host which value their setup supports. bash Copy ``` chmod 440 wp-config.php ``` 6. ### Step 6: Check the site Load a page, log in, and upload an image. Then look at "Filesystem Permissions" in Site Health again. ### Without a shell An SFTP program or the host's file manager can apply a mode to folders only or to files only. The permissions fix in how to fix the 403 Forbidden error (https://wpministry.co/errors/403-forbidden/) has those steps. On managed hosting where you have neither, ask the host to reset the site's permissions and ownership. Some control panels have a tool for it. If yours has none, ask support for folders at 755, files at 644, and every file owned by the account. ## Files and folders that need their own setting ### wp-config.php This file holds the database name, user and password. WordPress creates it at 644, and its documentation calls leaving it that way a hazard: on a shared server, 644 lets everyone else read it. The guidance is that only you and the web server can read it, which generally means 440 or 400. 400 lets the owner alone read it, which is enough where PHP runs as your account. 440 adds the group. At either value nobody can write to the file: to edit it, set it to 600, make the change, and set it back. ### .htaccess WordPress's documentation says 644 is normally required and recommended for this file. The web server has to read it, and a mode that shuts the server out causes an error. WordPress writes to `.htaccess` when you save your permalink settings. If it cannot, the Permalinks screen says "You should update your .htaccess file now." and shows the rules for you to paste into the file by hand. Pasting them is a complete answer. The file never needs to be writable by everyone. ### The uploads folder `wp-content/uploads` is the folder WordPress writes to day to day. When it cannot create a folder there, the upload fails with a message that starts "Unable to create directory", names the path, and asks "Is its parent directory writable by the server?" Where PHP runs as your account, the folder needs to be 755 and owned by that account. Where PHP runs as a separate user, the folder has to be writable by that user through its group, which is the 775 case above. On shared hosting set up that way, ask the host before you loosen anything. WordPress's documentation is plain about the limit: no folder is ever given 777, "even upload directories." ### The modes WordPress gives the files it writes When WordPress runs an update, it sets the modes itself: 755 for folders and 644 for files. Two constants in `wp-config.php` change that. WordPress's documentation says they exist for hosts that refuse to access files the group or everyone else can use. wp-config.php ``` define( 'FS_CHMOD_DIR', ( 0755 & ~ umask() ) ); define( 'FS_CHMOD_FILE', ( 0644 & ~ umask() ) ); ``` Add above the line that says to stop editing. Replace 0755 and 0644 with the values your host gives you. The values are octal: they start with a 0 and are not put in quotes. They apply to what WordPress writes from then on, not to files already in place. ## What wrong permissions look like - **A 403 on every page, or on images and stylesheets.** The web server cannot read a file or enter a folder. How to fix the 403 Forbidden error (https://wpministry.co/errors/403-forbidden/) covers this cause and the others. - **A 500 error.** Apache's suEXEC will not run a program that anyone but its owner can write to, or one in a folder like that. On a host that runs PHP through it, 777 causes an error and cures none. How to fix the 500 internal server error (https://wpministry.co/errors/500-internal-server-error/) shows how to find the line in the server's log. - **Uploads fail** with "Unable to create directory". See the uploads folder above. - **Updates fail.** WordPress says "Could not create directory." or "The update cannot be installed because some files could not be copied. This is usually due to inconsistent file permissions." Check ownership first. If the site is left broken, use the failed WordPress update runbook (https://wpministry.co/resources/failed-wordpress-update-runbook/). - **WordPress asks for FTP details.** PHP is not the owner of the files. ## Why 777 and 666 are never the answer 777 lets the owner, the group and everyone else read, write and execute. 666 does the same for reading and writing. "Everyone else" is not the public on the web. It is every other account and every process on the same server, which on shared hosting includes other customers' accounts. WordPress's documentation spells out the danger. Making your files writable by everyone gives the web server's own user, and anything that can hijack a process on the server, full access to them. The worst case it describes is someone uploading a file or changing one of yours to run their own code, which gives them control of the site, the database password included. And because write permission on a folder covers creating and removing files in it, a folder at 777 is open even when the files inside are 644. It is also not needed. Where PHP runs as your account, WordPress can write to a 755 folder. Where it does not, the cure is ownership or a shared group. The same page, where it covers the command line, still mentions 777 as a last and temporary resort. Its stricter advice is the one to follow. ## When to get help - **Ask the host** when `chmod` refuses a file or files belong to the wrong user. - **If folders were at 777 and you find PHP files you do not recognize,** see how to remove malware from a hacked WordPress site (https://wpministry.co/blog/remove-malware-hacked-wordpress-site/). - **Hand it over** if the modes and the ownership are right and the fault remains. A one-time fix (https://wpministry.co/services/one-time-fix/) from WP Ministry covers one issue on one site and starts with a free diagnosis, which gives you a written cause and a fixed quote. Permissions are one layer. WordPress security: what to do, in order of what matters most (https://wpministry.co/blog/ultimate-wordpress-security-guide/) puts them beside updates, backups and the rest. ## Common questions Are 755 and 644 right on every host? They are WordPress's general guidance, and its documentation says permissions differ from host to host. If your host publishes a scheme of its own, use it. What holds everywhere is the upper limit: nothing at 777 or 666. A plugin's instructions say to set a folder to 777. What do I do? Do not. WordPress's documentation says to ask the plugin's author or your server's support for a workaround. Where PHP runs as your account, WordPress can already write to the folder at 755. Can changing permissions delete or change my content? No. `chmod` changes who may read, write and execute a file, not what is in it. Wrong modes can take the site offline until they are corrected, which is why the steps above keep a record first. ## More on this subject - WordPress security and hacked sites: https://wpministry.co/topics/wordpress-security/ - Glossary term Malware: https://wpministry.co/glossary/malware/ - Glossary term Nonce: https://wpministry.co/glossary/nonce/ - Glossary term Salts and security keys: https://wpministry.co/glossary/salts-and-security-keys/ - Glossary term SSL certificate: https://wpministry.co/glossary/ssl-certificate/ - Glossary term Two-factor authentication (2FA): https://wpministry.co/glossary/two-factor-authentication/ - Glossary term Web application firewall (WAF): https://wpministry.co/glossary/web-application-firewall/ ## Not sure what is wrong? Tell us what you see. We reply with the cause and a fixed quote, and the diagnosis is free. Get a free diagnosis: https://wpministry.co/free-diagnosis/ May we measure how this site is used? A yes notes the pages of this visit and loads Google Analytics. A no keeps and loads nothing. See the cookies page (https://wpministry.co/legal/cookies/). If you say yes, we note the pages you look at during this visit and load Google Analytics. If you say no, nothing is kept and nothing is loaded. The site works the same either way. The cookies page (https://wpministry.co/legal/cookies/) has the details. ## Structured data ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://wpministry.co/#organization", "name": "WP Ministry", "url": "https://wpministry.co/", "logo": "https://wpministry.co/brand/logo.png", "address": { "@type": "PostalAddress", "streetAddress": "1309 Coffeen Ave STE 1200", "addressLocality": "Sheridan", "addressRegion": "WY", "postalCode": "82801", "addressCountry": "US" }, "sameAs": [ "https://www.linkedin.com/company/wp-ministry/", "https://x.com/wpministryco", "https://www.instagram.com/wpministryco/", "https://www.facebook.com/wpministryco", "https://www.tiktok.com/@wpministryco", "https://www.pinterest.com/wpministryco/", "https://www.youtube.com/channel/UCOZRuAukk5QSTRPG6BaHl3Q" ] }, { "@type": "WebSite", "@id": "https://wpministry.co/#website", "name": "WP Ministry", "url": "https://wpministry.co/", "inLanguage": "en-US", "publisher": { "@id": "https://wpministry.co/#organization" } }, { "@type": "Article", "@id": "https://wpministry.co/blog/wordpress-file-permissions-guide/#article", "headline": "WordPress file permissions: what the numbers mean and what to set", "description": "WordPress's guidance is 755 for folders, 644 for files and 440 or 400 for wp-config.php, with every file owned by your hosting account. Nothing should be 777.", "url": "https://wpministry.co/blog/wordpress-file-permissions-guide/", "mainEntityOfPage": "https://wpministry.co/blog/wordpress-file-permissions-guide/", "inLanguage": "en-US", "image": "https://wpministry.co/og/blog/wordpress-file-permissions-guide.png", "author": { "@id": "https://wpministry.co/#organization" }, "publisher": { "@id": "https://wpministry.co/#organization" }, "datePublished": "2026-10-07T00:00:00.000Z", "dateModified": "2026-10-07T00:00:00.000Z" }, { "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://wpministry.co/" }, { "@type": "ListItem", "position": 2, "name": "Guides", "item": "https://wpministry.co/blog/" }, { "@type": "ListItem", "position": 3, "name": "WordPress file permissions: what the numbers mean and what to set" } ] } ] } ```