---
title: "WordPress file permissions: 644, 755 and the wp-config.php case"
description: "WordPress file permissions: what 644 and 755 mean, why wp-config.php should be 400 or 440, and the values (like 777) you should never use."
language: "en"
locale: "en-US"
type: "article"
canonical: "https://www.wp-masquerade.com/wordpress-file-permissions/"
published: "2026-10-15T07:00:00+00:00"
modified: "2026-10-28T20:26:04+00:00"
translations:
  en-US: "https://www.wp-masquerade.com/wordpress-file-permissions/index.md"
  fr-FR: "https://www.wp-masquerade.com/fr/permissions-fichiers-wordpress/index.md"
  es-ES: "https://www.wp-masquerade.com/es/permisos-archivos-wordpress/index.md"
  de-DE: "https://www.wp-masquerade.com/de/wordpress-dateiberechtigungen/index.md"
  it-IT: "https://www.wp-masquerade.com/it/permessi-file-wordpress/index.md"
  pt-BR: "https://www.wp-masquerade.com/pt/permissoes-arquivos-wordpress/index.md"
  nl-NL: "https://www.wp-masquerade.com/nl/bestandsrechten-wordpress/index.md"
---

# WordPress file permissions: 644, 755 and the wp-config.php case

644, 755, wp-config.php at 400: WordPress permission rules fit in a handful of numbers. Here they are, and what you should never do.

File permissions are one of those topics people put off until the day an upload error or a misunderstood tip turns a site into a sieve. Yet the rules fit in a handful of numbers. This article explains what 644 and 755 mean, why `wp-config.php` deserves special treatment, and which values are genuinely dangerous on WordPress hosting.

## Reading a permission in thirty seconds

On Linux, every file carries three sets of rights: the owner, the group, and others (everyone else). For each set, three actions are possible: read (r), write (w), execute (x). The numbers you see (644, 755) are simply these rights translated into octal notation, where read is worth 4, write 2 and execute 1.

- **644** corresponds to `rw-r--r--`: the owner reads and writes, the group and others can only read. This is the normal value for files.
- **755** corresponds to `rwxr-xr-x`: the owner has all rights, the group and others can read and traverse. The execute bit on a directory lets you enter it, not run a program. This is the normal value for directories.

![Breakdown of permissions 644 into rw- r-- r-- and 755 into rwx r-x r-x, with a reminder that wp-config.php should be 400 or 440 and that 777 must never be used.](https://www.wp-masquerade.com/media/2026/10/permissions-en.webp)

*The two reference values for WordPress, and the exceptions to know.*

## Recommended values for WordPress

The official WordPress documentation gives a simple scheme: all directories at 755 and all files at 644. These values let the web server read and serve the site, while reserving write access for the owner of the files. They are enough for the vast majority of installations.

| Target | Recommended value | Why |
| --- | --- | --- |
| Directories | 755 | The server can traverse them, only the owner writes |
| Files | 644 | Public read access, write access reserved for the owner |
| wp-config.php | 400 or 440 | Contains the database credentials and secret keys |
| .htaccess | 644 (sometimes 444) | Read by the server; 444 if no plugin needs to write to it |
| wp-content/uploads | 755, no PHP execution | An uploaded file must never be able to execute |

*Recommended permission scheme, to adapt to your host's configuration.*

## The special case of wp-config.php

This file holds the site's secrets: database login credentials, authentication keys and salts. The WordPress documentation recommends making sure that only you and the web server can read it, which generally translates into a 400 or 440 permission. The idea is to remove all rights from other users on the server, a sensitive point on [shared hosting](https://www.wp-masquerade.com/glossary/shared-hosting/) where several sites share the same machine.

Be careful, though: some hosts require 640, 600 or even 644 for their PHP configuration to work. A good method is to aim for the strictest value, then loosen it by one notch only if the site returns an error. Always test that the site displays correctly after a change.

## What is genuinely dangerous

The real trap is not choosing 755 over 750. It is applying, often on the strength of a hastily found tip, permissions that are far too open just to make a "permission denied" error go away.

- **777 on a directory or file.** This allows any user on the server to write, and therefore to replace a PHP file with [malicious code](https://www.wp-masquerade.com/glossary/malware/). If an attacker gains an entry point through a vulnerable plugin, a 777 directory gives them a place to drop and run their payload. Never use 777.
- **PHP execution in the uploads directory.** A form that accepts poorly filtered files, combined with an `uploads` directory able to execute PHP, is a classic recipe for a takeover. This directory should serve media, not run scripts.
- **A world-readable wp-config.php.** On a poorly isolated shared server, a publicly readable configuration file exposes your database credentials.

## Owner and group: the other half of the topic

Permissions do not tell the whole story. You also need to know who owns the files. Two setups exist on modern hosting.

- **The web server runs under your user account** (common with per-pool [PHP-FPM](https://www.wp-masquerade.com/glossary/php-fpm/), or with suPHP). The files belong to you, and 644 or 755 are enough for WordPress to write when it updates a plugin.
- **The web server runs under a separate account** (for example `www-data`). That account then needs to belong to your group, and you sometimes have to allow group write access, without ever opening it to "others".

In practice, your host has already chosen a model. Before changing anything, take a full backup and find out how it is configured. Permissions that are too strict break automatic updates; permissions that are too loose make an attacker's life easier.

## Restoring order in two commands

If your permissions are inconsistent, the WordPress documentation suggests resetting them with two commands, to run from the site root over SSH:

```
find /path/to/site/ -type d -exec chmod 755 {} \;
find /path/to/site/ -type f -exec chmod 644 {} \;
```

Then apply the strict value to `wp-config.php` with `chmod 400 wp-config.php`, and check that the site and the admin area respond normally. If you do not have SSH access, most file managers and FTP clients let you set these same values on a directory and its contents.

## Where WP Masquerade fits in

Let us be clear: WP Masquerade modifies neither core files nor the server configuration, and therefore does not change your permissions for you. Setting permissions remains a task to carry out at the hosting level. The plugin works on a different, complementary level.

On the one hand, it makes its own files (readme, translations, PHP files) invisible to scanners on Apache, LiteSpeed and o2switch, which reduces the clues a bot can collect. On the other hand, its [WordPress core integrity check](https://www.wp-masquerade.com/features/wordpress-integrity-check/) compares your files with the official versions and flags any unexpected change, the typical symptom of a file rewritten thanks to overly open permissions. Finally, managing [file URLs](https://www.wp-masquerade.com/features/file-url-aliases/) makes the standard paths harder to spot. These measures do not replace correct permissions: they add to a sound foundation.

## Checking the current state of your files

Before fixing anything, you need to know where you are starting from. Over SSH, the `ls -l` command shows permissions as letters, and `stat` gives the exact octal value of a file. Many hosting file managers and FTP clients also display these rights, often in a "Permissions" column or by right-clicking the file.

Focus on a few sensitive spots: `wp-config.php`, the `wp-content/uploads` directory, the `.htaccess` file at the root, and any directory showing 777. Spotting a single anomaly in these places is worth more than reviewing thousands of files that behave normally.

## When a permission breaks a feature

Permissions that are too strict also have visible effects, and it helps to be able to trace them back to their cause. A plugin update that fails, a media file that cannot be uploaded, a cache file that does not get created: these symptoms often point to a permissions or ownership problem rather than a WordPress bug.

The temptation is then to open permissions wide so that "it works". That is the mistake to avoid. The right approach is to understand which account needs to write where. On shared hosting, the host usually has the answer, and its support team can tell you whether the web server runs under your account or under a separate one. A question to support costs less than a site exposed by a 777 left in place "just while testing", then forgotten.

### Key takeaways

- Basic rule: directories at 755, files at 644.
- wp-config.php: aim for 400 or 440, loosen only if your host requires it.
- Never use 777, and prevent PHP execution in the uploads directory.
- Back up before making changes, then test the site and the admin area.

## Sources

- [WordPress Developer, Hardening WordPress (file permissions)](https://developer.wordpress.org/advanced-administration/security/hardening/)
- [WordPress Developer, Changing File Permissions](https://developer.wordpress.org/advanced-administration/server/file-permissions/)

## WordPress security, without the noise

One e-mail when something matters: new attacks seen in the wild, plugin updates and practical guides. No spam, unsubscribe in one click.