The wp-config.php file is the most important configuration file in any WordPress installation. It stores your database credentials, security keys, and dozens of settings that control how your site behaves — from debug mode to memory limits. This guide explains what wp-config.php is, where to find it, how to edit it without breaking your site, and every key setting worth knowing. Because a single wrong character can take your whole site down, the golden rule comes first: always back it up before you touch it.
The wp-config.php file controls your database connection and site security. A single typo can take your site offline. Before making any change, download a copy of the file — if something breaks, you just re-upload the original.
Table of Contents
What is the wp-config.php file?
The wp-config.php file is a PHP file that lives in the root of your WordPress installation and holds the site’s core configuration. It tells WordPress which database to connect to, with which credentials, and defines behaviors like security keys, table prefix, debug mode, and resource limits.
One key thing to know: wp-config.php doesn’t ship with WordPress. A fresh download includes a template called wp-config-sample.php. During installation, WordPress fills in your details and generates the real wp-config.php automatically — or you can create it yourself by renaming the sample file and filling in your database information.
Without this file (or with it misconfigured), WordPress can’t load, and you get the classic error establishing a database connection.
Where to find it
The wp-config.php file sits in the root directory of your WordPress install — usually the public_html folder, alongside wp-admin, wp-content, and wp-login.php. You reach it through your hosting File Manager (in cPanel), or an FTP client like FileZilla, or over SSH.
On a standard install the path looks like public_html/wp-config.php. If WordPress is installed in a subfolder, it’s inside that folder instead.
How to edit wp-config.php safely
There are three common ways to edit the file. Whichever you choose, back it up first — and never edit it in a word processor like Word or Google Docs, which inject formatting that corrupts PHP. Use a plain-text or code editor.
You may also see plugins that let you edit wp-config.php from the dashboard. We don’t recommend them: editing this file through a plugin requires loose file permissions that are themselves a security risk, and if a change breaks the site, you lose the very dashboard you’d use to undo it. Stick to the three methods below, always with a backup.
Method 1 — cPanel File Manager
The easiest route on most hosts. In cPanel, open File Manager → public_html, right-click wp-config.php, and choose Edit. Make your change and save. On Copahost’s cPanel you can do this directly, no FTP needed.
Method 2 — FTP (FileZilla)
Connect to your site with an FTP client, navigate to the root folder, download wp-config.php, edit it locally in a plain-text editor, then upload it back, overwriting the original. Keep the copy you downloaded as your backup.
Method 3 — SSH
On a VPS or any plan with shell access, edit the file directly with a terminal editor like nano: nano wp-config.php. Save with Ctrl+O and exit with Ctrl+X. Fastest if you’re comfortable on the command line.
Download the file, edit the copy locally, then re-upload — never edit the live file directly if you can avoid it. Add your custom lines above the line that reads /* That's all, stop editing! */. Anything after it is ignored or breaks the file.
The main sections of wp-config.php
Database connection settings
The most critical block — without it, the site won’t run. It holds the four pieces WordPress needs to reach your database:
define( 'DB_NAME', 'database_name' );
define( 'DB_USER', 'database_user' );
define( 'DB_PASSWORD', 'your_password' );
define( 'DB_HOST', 'localhost' );DB_NAME is your MySQL database name, DB_USER the user with access to it, DB_PASSWORD that user’s password, and DB_HOST the database server address (usually localhost, but some hosts use a specific hostname — check with yours; a non-standard port looks like localhost:3307). If any of these are wrong, you’ll see the “error establishing a database connection” message.
Security keys and salts
Below the database block sit eight security keys (the keys and salts). They encrypt session and cookie data, making it far harder for an attacker to forge a login:
define( 'AUTH_KEY', '...' );
define( 'SECURE_AUTH_KEY', '...' );
define( 'LOGGED_IN_KEY', '...' );
define( 'NONCE_KEY', '...' );
define( 'AUTH_SALT', '...' );
define( 'SECURE_AUTH_SALT', '...' );
define( 'LOGGED_IN_SALT', '...' );
define( 'NONCE_SALT', '...' );Briefly: AUTH_KEY / SECURE_AUTH_KEY / LOGGED_IN_KEY sign and encrypt the login cookies; NONCE_KEY helps protect forms and URLs from misuse; the four _SALT values add extra randomness (salting) so cookie hashes can’t be reversed with precomputed tables.
Never invent these by hand. WordPress has an official generator that outputs all eight with secure randomness: visit api.wordpress.org/secret-key/1.1/salt/, copy the result, and replace the matching lines. Changing these keys also logs out every active user — handy if you suspect an account has been compromised.
Table prefix
Sets the prefix for your WordPress database tables. The default is wp_:
$table_prefix = 'wp_';Because wp_ is universally known, using a custom prefix (like wpx3_) at install time is a small security hardening step against automated SQL attacks. Careful: changing the prefix on a live site also requires renaming the database tables, or the site breaks — do it at install time or with a dedicated plugin.
Debug mode (WP_DEBUG)
Controls whether WordPress shows PHP errors and warnings. It’s false by default:
define( 'WP_DEBUG', false );When troubleshooting (a white screen or critical error), switch it to true. To log errors to a file instead of showing them to visitors, combine:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true ); // logs to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // hides errors from visitorsThis writes everything to your WordPress error log. Never leave debug on on a live site — it exposes file paths and code details to attackers. Turn it off once you’re done. For a full tutorial on enabling debug mode, reading the log, and the tools that help, see our guide to WordPress debug mode.
The absolute path (don’t touch)
At the end of the file sits the block that sets the absolute path and loads WordPress. Never add anything below it — your custom lines always go above the “stop editing” comment:
/* That's all, stop editing! Happy publishing. */if ( ! defined( 'ABSPATH' ) ) {
define( 'ABSPATH', __DIR__ . '/' );
}
require_once ABSPATH . 'wp-settings.php';Useful constants you can add to wp-config.php
Beyond the basics, wp-config.php accepts dozens of constants that tune security, performance, and behavior. The most useful:
The WP_HOME and WP_SITEURL constants are also the first place to check if you’re stuck in a login redirect loop — see our WordPress login guide for the full fix. Related: if you edit your theme’s code, see our guide to the functions.php file.
How to check your current WordPress settings
After editing wp-config.php, you’ll want to confirm your changes actually took effect — especially for values like the memory limit, which the server can override. WordPress has a built-in tool for this. In your dashboard, go to Tools → Site Health → Info, then expand the Server section. There you’ll see the active PHP memory limit, PHP version, and other environment values your site is really running under.
This matters because WP_MEMORY_LIMIT only requests memory — it can never exceed the server’s PHP memory_limit. If you set 256M in wp-config.php but Site Health still shows 128M, your host’s server cap is the real ceiling, and you’ll need to raise it at the server level or contact support. For the full breakdown of memory settings, see our guide on the WordPress memory limit and the “allowed memory size exhausted” error.
How to protect wp-config.php
Since this file holds your database credentials, protecting it matters. Four proven measures:
1. Block browser access via .htaccess. Add this to the .htaccess file in your root (Apache):
<files wp-config.php>
order allow,deny
deny from all
</files>2. Set correct file permissions. wp-config.php should be 600 (owner read/write only) or 644 at most. Never 777. You can set this in your File Manager or over SSH with chmod 600 wp-config.php. For the complete guide to permissions across your whole site, see our WordPress file permissions guide.
3. Move it one level up. WordPress automatically looks one directory above the root for wp-config.php if it’s not found in the root. Moving it out of public_html puts it beyond direct web access — a simple, effective hardening step. Two caveats: it only works one level up (not deeper), and if you run multiple WordPress installations, each looks in its own parent folder, so don’t move a shared config where another install expects it. For a single site, it’s a safe and worthwhile move.
4. Use strong keys and a custom table prefix, as covered above, plus general good practice: strong passwords, updated plugins, and a security plugin like Wordfence.
Since WordPress 5.2, if a fatal error takes your site down — including a syntax error in wp-config.php — WordPress enters Recovery Mode instead of showing a blank screen. It emails the site administrator a special login link that lets you access the dashboard in a safe mode to fix or undo the problem. So if an edit breaks your site, check the admin email inbox first.
First, re-upload your backup copy of wp-config.php to restore the previous state. If you didn’t keep one, check the admin email for the WordPress Recovery Mode link, or fix the file directly via FTP or File Manager. A critical error message almost always points to a syntax mistake — a missing semicolon or quote.
Setting up databases and wp-config.php can be intimidating. With Copahost, WordPress comes installed and configured, with cPanel access, automatic backups, and support that answers when you need to dig into the details.
See web hosting plansFrequently asked questions
Where is the wp-config.php file located?
In the root directory of your WordPress install, usually the public_html folder, alongside wp-admin and wp-content. You reach it through your hosting File Manager, FTP, or SSH.
My site has no wp-config.php. Is that normal?
The file doesn’t ship with WordPress — a fresh download includes wp-config-sample.php instead. WordPress generates the real wp-config.php during installation, or you can create it by renaming the sample file and filling in your database details.
Is it safe to edit wp-config.php?
Yes, as long as you back it up first and edit carefully. Because the file controls your database connection, a single typo can take the site down — but restoring your backup copy brings it right back. Always add new lines above the “That’s all, stop editing!” comment.
What causes “error establishing a database connection” from wp-config.php?
Almost always wrong database details. Check that DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST match your database credentials in the hosting panel. If they’re correct, the database server may be down — contact support.
How do I enable debug mode in wp-config.php?
Change define(‘WP_DEBUG’, false); to true. To log errors to a file instead of showing them to visitors, add WP_DEBUG_LOG as true and WP_DEBUG_DISPLAY as false. Turn it off when you’re done.
Family of errors
The wp-config.php file connects to several common WordPress issues — see our guides on error establishing a database connection, the white screen of death, and WordPress error logs, plus our hub of common WordPress errors.
Conclusion
The wp-config.php file is the heart of WordPress configuration: it connects your site to its database, secures access with keys and salts, and lets you tune dozens of behaviors through constants. You won’t edit it daily — but knowing what each part does helps you fix errors, harden security, and optimize your site when you need to. The essential rule never changes: back it up before editing, change one thing at a time, and test your site right after.
