LiveChat 
Support 
wp-config.php Explained: The WordPress Configuration File
If you have ever set up a WordPress site, you have touched `wp-config.php` — even if a one-click installer wrote it for you. It is the file WordPress reads before anything else, and without it WordPress simply will not boot. It defines how WordPress talks to your database, how it secures user sessions, and dozens of behaviors you can tune with PHP constants. It is also the single most security-sensitive file in your entire install, because it stores your database password in plaintext.
This guide breaks down `wp-config.php` from an engineer’s perspective: what it contains, the constants worth knowing, how to lock it down, and how to edit it without white-screening your site.
Key Takeaways
• `wp-config.php` lives at the WordPress root and holds database credentials, security salts, and PHP constants that control core behavior.
• It stores your DB password in plaintext, so it is the highest-value target in a WordPress install — set permissions to `640` or `600`, deny direct HTTP access, and never commit it to a public repo.
• Useful constants like `WP_DEBUG`, `DISALLOW_FILE_EDIT`, `WP_MEMORY_LIMIT`, and `FORCE_SSL_ADMIN` let you control debugging, security, and performance without touching core code.
• A single syntax error will take the whole site down (the dreaded white screen), so always back it up before editing.
• WordPress lets you move `wp-config.php` one directory above the web root for an extra layer of protection.
What is wp-config.php and why can’t WordPress run without it?
`wp-config.php` is the core configuration file for a WordPress installation. It sits at the root of your WordPress directory — the same folder that contains `wp-load.php`, `wp-settings.php`, and the `wp-admin` / `wp-content` directories.
When a request hits WordPress, `wp-load.php` looks for `wp-config.php`. If it cannot find it, WordPress assumes the site is not yet installed and redirects you to the setup screen. If the file exists but contains bad PHP, the request dies. Everything downstream — connecting to the database, loading plugins, rendering a page — depends on values defined here.
Fresh WordPress downloads ship with `wp-config-sample.php` instead of `wp-config.php`. This is a template. During installation, WordPress (or you, manually) copies it to `wp-config.php` and fills in the real values. The sample file is harmless if left in place, but some hardening guides recommend deleting it because it advertises your WordPress version indirectly.
What database settings does wp-config.php define?
The most important job of `wp-config.php` is telling WordPress how to reach its MySQL/MariaDB database. These four constants are mandatory:
“`php /** The name of the database for WordPress */ define( ‘DB_NAME’, ‘wordpress_db’ );
/** Database username */ define( ‘DB_USER’, ‘wp_user’ );
/** Database password */ define( ‘DB_PASSWORD’, ‘a-strong-password-here’ );
/** Database hostname */ define( ‘DB_HOST’, ‘localhost’ ); “`
Two more control character encoding:
“`php /** Database charset to use in creating database tables */ define( ‘DB_CHARSET’, ‘utf8mb4’ );
/** The database collate type. Don’t change this if in doubt. */ define( ‘DB_COLLATE’, ” ); “`
`DB_HOST` is often `localhost`, but on managed platforms it can be a separate hostname, an IP, or include a port or socket (for example `127.0.0.1:3306` or `localhost:/var/run/mysqld/mysqld.sock`). `DB_CHARSET` should be `utf8mb4` on any modern install — it supports the full Unicode range, including emoji.
Below those, you will find the table prefix, which is a variable, not a constant:
“`php $table_prefix = ‘wp_’; “`
Every WordPress table (`wp_posts`, `wp_users`, and so on) uses this prefix. Choosing a non-default prefix at install time is a mild obscurity measure against automated SQL injection scripts that assume `wp_`. Note that changing it after installation requires renaming tables and updating serialized options — it is not a one-line edit.
What are the security keys and salts?
Below the database block, WordPress defines eight authentication unique keys and salts:
“`php define( ‘AUTH_KEY’, ‘long-random-string’ ); define( ‘SECURE_AUTH_KEY’, ‘long-random-string’ ); define( ‘LOGGED_IN_KEY’, ‘long-random-string’ ); define( ‘NONCE_KEY’, ‘long-random-string’ ); define( ‘AUTH_SALT’, ‘long-random-string’ ); define( ‘SECURE_AUTH_SALT’, ‘long-random-string’ ); define( ‘LOGGED_IN_SALT’, ‘long-random-string’ ); define( ‘NONCE_SALT’, ‘long-random-string’ ); “`
These are secret values used to hash and encrypt the cookies that keep users logged in, plus the nonces that protect forms against CSRF. They make it computationally impractical to forge a valid WordPress session cookie.
WordPress provides an official generator at the secret-key API (`https://api.wordpress.org/secret-key/1.1/salt/`), which returns eight ready-to-paste `define()` lines. Generate a fresh set there whenever you suspect compromise.
A practical security move: regenerating these keys instantly invalidates every active session. If a site is breached, replacing all eight salts logs out every user — including any attacker riding a stolen cookie. Legitimate users simply log in again.
Which wp-config.php constants are worth knowing?
Beyond the database and salts, `wp-config.php` is where you tune WordPress with PHP constants. Here are the ones engineers reach for most.
| Constant | Example value | Purpose |
|---|---|---|
| `WP_DEBUG` | `true` | Enables PHP error and notice reporting |
| `WP_DEBUG_LOG` | `true` | Writes errors to `wp-content/debug.log` instead of the screen |
| `WP_DEBUG_DISPLAY` | `false` | Suppresses on-screen errors (use with logging) |
| `WP_MEMORY_LIMIT` | `’256M’` | Raises PHP memory available to WordPress |
| `DISALLOW_FILE_EDIT` | `true` | Disables the dashboard theme/plugin file editor |
| `WP_HOME` | `’https://example.com’` | Sets the site address WordPress serves from |
| `WP_SITEURL` | `’https://example.com’` | Sets the URL where WordPress core lives |
| `FORCE_SSL_ADMIN` | `true` | Forces HTTPS for logins and the admin area |
| `AUTOSAVE_INTERVAL` | `120` | Seconds between editor autosaves |
| `WP_POST_REVISIONS` | `5` | Caps stored revisions per post (or `false` to disable) |
A few deserve elaboration.
`WP_DEBUG` should be `false` in production. For diagnosing an issue, combine three constants so errors land in a log file rather than leaking to visitors:
“`php define( ‘WP_DEBUG’, true ); define( ‘WP_DEBUG_LOG’, true ); // logs to wp-content/debug.log define( ‘WP_DEBUG_DISPLAY’, false ); // keep errors off the page @ini_set( ‘display_errors’, 0 ); “`
`DISALLOW_FILE_EDIT` is one of the cheapest security wins available. Setting it to `true` removes the built-in code editor from the dashboard, so a compromised admin account cannot inject PHP into your theme through the browser:
“`php define( ‘DISALLOW_FILE_EDIT’, true ); “`
`WP_HOME` and `WP_SITEURL` hard-code your URLs, which is useful when migrating between domains or environments because they override the values stored in the database.
Why is wp-config.php the most security-sensitive file?
Here is the part that gets underestimated: `wp-config.php` contains your database credentials in plaintext. There is no encryption, no hashing — `DB_PASSWORD` sits there as a readable string. That makes it the single most security-sensitive file in a WordPress install. A leaked `wp-config.php` hands an attacker your entire database: every user record, password hash, and private post. Treat the file like the secret it is.
Three controls matter most.
Set strict file permissions. WordPress only needs to read this file, so remove write and world access. On a typical setup:
“`bash
chmod 640 wp-config.php
chmod 600 wp-config.php “`
The correct value depends on whether your web server runs as the file owner or as a group member; `640` is a safe default on most shared and managed environments, `600` where the web server process is the file owner.
Deny direct HTTP access. A misconfigured server could serve the raw file if PHP fails to execute. On Apache, block it explicitly:
“`apache
On Nginx, the equivalent:
“`nginx location ~* /wp-config\.php { deny all; } “`
Never commit it to a public repository. If you version-control your site, add `wp-config.php` to `.gitignore`. Countless credential leaks trace back to a `wp-config.php` pushed to a public GitHub repo. For local development, keep secrets in environment variables and read them in:
“`php define( ‘DB_PASSWORD’, getenv( ‘WP_DB_PASSWORD’ ) ); “`
One more structural option: WordPress will look one directory above the web root for `wp-config.php` if it is not found in the root. Moving it there places your credentials outside any web-accessible path entirely:
“` /home/user/ ├── wp-config.php ← moved here, outside public_html └── public_html/ ← document root ├── wp-admin/ ├── wp-content/ └── index.php “`
How do you edit wp-config.php safely?
`wp-config.php` is plain PHP, so the rules of PHP apply: one missing semicolon or stray character produces a fatal parse error, and because this file loads before everything else, that error white-screens the entire site — front end and dashboard alike.
Edit defensively:
- Back it up first. Copy `wp-config.php` to `wp-config.php.bak` before changing anything. If the edit breaks the site, restore the backup and you are live again in seconds.
- Add constants above the stop line. Near the bottom you will see `/* That’s all, stop editing! Happy publishing. */`. Place your `define()` statements above that comment.
- Match the syntax exactly. String values need quotes; booleans (`true` / `false`) do not. Every statement ends in a semicolon.
- Avoid a closing `?>` tag. WordPress recommends omitting the closing PHP tag in config files. A trailing space after `?>` can emit output and trigger “headers already sent” errors.
If you do white-screen the site, enabling `WP_DEBUG_LOG` (if it was already on) or restoring your backup is the fastest path back.
Run WordPress on hosting that handles wp-config.php correctly
The safest `wp-config.php` is one your host already locks down for you. DarazHost WordPress hosting ships with secure file handling out of the box: correct `wp-config.php` permissions and direct web access denied by default, so your database credentials are not exposed by a server misstep.
When you do need to edit a constant, you get straightforward access through the File Manager and SFTP, plus staging environments to test changes before they touch production and automated backups to roll back a bad edit in one click. It is security-focused hosting backed by 24/7 support — so a syntax slip never has to mean a downed site.
Frequently asked questions
Where is wp-config.php located? In the root directory of your WordPress installation — the same folder as `wp-load.php` and the `wp-admin` directory (commonly `public_html` or `www`). WordPress also checks the directory one level above the root, which is a supported and more secure location.
Can WordPress run without wp-config.php? No. WordPress reads it during bootstrap to get database credentials and security keys. If the file is missing, WordPress redirects to the installation wizard; if it exists but contains invalid PHP, the site fails to load entirely.
What happens if I change the security keys and salts? Every logged-in user is immediately signed out and must log in again, because their existing session cookies become invalid. This is a deliberate and useful response to a suspected breach. Regenerate fresh values from the WordPress secret-key API.
What file permissions should wp-config.php have? Use `640` (owner read/write, group read) on most managed and shared setups, or `600` (owner only) where the web server runs as the file owner. Never use `777` or any world-writable mode.
Why did my site go blank after editing wp-config.php? Almost always a PHP syntax error — a missing semicolon or quote, or an extra character outside the PHP tags. Restore your backup, or fix the typo. Enabling `WP_DEBUG_LOG` helps surface the exact line in `wp-content/debug.log`.
