On This Page: [hide]
One stray character in wp-config.php, a missing semicolon or a deleted quote, and your entire WordPress site turns into a white screen. That same file is also where you fix slow admin pages, lock out the dashboard code editor, and switch on the log that tells you what actually broke. It’s the most powerful file in your install and the easiest one to wreck.
Quick answer: wp-config.php is the PHP file in your WordPress root folder that holds your database login, your security keys, and dozens of optional settings WordPress reads before the rest of the site loads. You’ll find it next to the wp-admin and wp-content folders. Edit it through your host’s File Manager or SFTP, use a plain text editor (never Word), and back it up before you touch a single line.
Last reviewed: June 2026. Settings verified against WordPress 7.0 and the official developer.wordpress.org documentation.
What wp-config.php Actually Does (and Where to Find It)
WordPress loads wp-config.php near the very start of every request, before most of the core code runs. The file’s job is to define a handful of PHP constants and one variable (the table prefix) that tell WordPress how to connect to its database and how to behave. No working wp-config.php means no site. Full stop.
You’ll find it in your WordPress root directory, the same folder that holds wp-admin, wp-includes, and wp-content. On most shared hosts that folder is called public_html or www. On a VPS it’s usually something like /var/www/html.
Fresh downloads of WordPress don’t ship with wp-config.php at all. They ship with wp-config-sample.php. The famous five-minute install copies that sample, fills in your database details, and saves the result as the real file. If you ever see wp-config-sample.php sitting in your root, that’s the template, not the live config. Editing it does nothing.
Here’s the part people miss: even on WordPress 7.0, this file works exactly the way it did a decade ago. The constants change and new ones get added, but the mechanism is the same plain-PHP setup. That’s why one outdated tutorial can still break a modern site. Many managed WordPress hosting platforms now lock, hide, or partly auto-generate this file, so check your host’s rules before you go editing.
How to Edit wp-config.php Safely
Back up the file first. Always. Download a copy to your computer before you change anything, so a bad edit is a 30-second restore instead of a midnight panic. This matters even more if you’re in the middle of a site migration, where the database details are already in flux.
You have four common ways in:
- File Manager (cPanel/host panel): Find the file, right-click, choose Edit. Easiest for beginners, no software needed.
- SFTP or FTP: Connect with a client like FileZilla, download the file, edit locally, upload it back. Best when you want a local copy anyway.
- WP-CLI: Run
wp config set WP_DEBUG true --rawfrom the command line. Fast and typo-proof once you’re set up. - SSH with nano or vim: Edit straight on the server. For people who live in the terminal.
Two rules keep you out of trouble. Use a code editor or plain text editor (VS Code, Notepad, nano), never a word processor. Word and Pages add invisible formatting characters that turn valid PHP into garbage. And put new lines above the comment that reads:
/* That's all, stop editing! Happy publishing. */
Anything you paste below that line can get ignored or, worse, break the file. PHP is picky too. Every define() needs its quotes, its comma, and a closing semicolon. Miss one and you get the white screen of death. So edit, save, then reload your site in a new tab before you close the editor. If it loads, you’re good.
wp-config.php Constants Cheat Sheet
Before the deep dive, here’s the fast map: the constants you’ll actually reach for, with their defaults where one exists. Each gets a full explanation further down.
DB_NAME,DB_USER,DB_PASSWORD,DB_HOST: the database connection (required, no defaults).$table_prefix: database table prefix (defaultwp_).- The eight
AUTH_KEYandAUTH_SALTlines: login cookie security (no default, you generate them). WP_DEBUG,WP_DEBUG_LOG,WP_DEBUG_DISPLAY: error logging (all off by default).WP_MEMORY_LIMIT: front-end PHP memory (default 40M, 64M on multisite).WP_POST_REVISIONS: stored edit history (default unlimited).AUTOSAVE_INTERVAL: editor autosave gap (default 60 seconds).EMPTY_TRASH_DAYS: trash retention (default 30 days).DISABLE_WP_CRON: turn off the visitor-triggered scheduler (default: the scheduler runs).DISALLOW_FILE_EDIT: kill the dashboard code editor (default: editing allowed).FORCE_SSL_ADMIN: force HTTPS on login and admin (default off).FS_METHOD: how WordPress writes files (default: auto-detected).WP_AUTO_UPDATE_CORE: core auto-update policy (defaultminor).WP_ENVIRONMENT_TYPE: site label, local / development / staging / production (defaultproduction).WP_HOME,WP_SITEURL: hardcoded site address (no default, read from the database).
The Required Settings: Database Credentials
Four values are non-negotiable. Without them WordPress can’t reach its database, and you’ll see the dreaded “Error establishing a database connection” message instead of your homepage.
define( 'DB_NAME', 'your_database_name' ); define( 'DB_USER', 'your_database_user' ); define( 'DB_PASSWORD', 'your_strong_password' ); define( 'DB_HOST', 'localhost' );
DB_HOST is localhost on most shared hosting, but plenty of hosts use a dedicated database server with a different address or a non-standard port (written as hostname:3307). When a connection fails and your username and password are right, the host value is the usual culprit. Check your host’s documentation for the exact string.
Two more database lines round it out. DB_CHARSET is set to utf8mb4 on current installs, the character set that supports emoji and the full range of world languages. DB_COLLATE stays empty in almost every case, which lets MySQL pick the right sorting rules automatically.
Then there’s the table prefix, which isn’t a constant but a variable:
$table_prefix = 'wp_';
The default is wp_. Some security guides tell you to change it to something random to dodge automated SQL injection attacks. Honestly, the protection is thin against any attacker who’s already in your database, and changing it on a live site means renaming tables and updating two serialized values by hand. Set a custom prefix at install time if you like. Don’t bother rewriting it on a running site just for security theater.
Security Keys and Salts
Below the database block sits a wall of long random strings: eight of them, four “keys” and four “salts.”
define( 'AUTH_KEY', 'long-random-string-here' ); define( 'SECURE_AUTH_KEY', 'long-random-string-here' ); define( 'LOGGED_IN_KEY', 'long-random-string-here' ); define( 'NONCE_KEY', 'long-random-string-here' ); define( 'AUTH_SALT', 'long-random-string-here' ); define( 'SECURE_AUTH_SALT', 'long-random-string-here' ); define( 'LOGGED_IN_SALT', 'long-random-string-here' ); define( 'NONCE_SALT', 'long-random-string-here' );
These scramble the login cookies and session tokens WordPress stores in your browser. With strong, unique values, a stolen cookie is far harder to fake. You never type these keys and you never need to remember them. They just need to be long, random, and different on every site.
WordPress runs a free generator for exactly this. Visit https://api.wordpress.org/secret-key/1.1/salt/ in your browser and it returns eight fresh lines. Copy them straight over the old block. Done.
Here’s the genuinely useful trick: changing these values logs out every user instantly, including any attacker riding a hijacked session. After a suspected breach, password resets alone won’t kick an intruder whose cookie is still valid. Rotating the salts will. It’s the fastest “log everyone out everywhere” button WordPress has.
Debug Mode: Turning On the Error Log
When something breaks and you’ve no idea why, wp-config.php holds the flashlight. The main switch is WP_DEBUG, off by default:
define( 'WP_DEBUG', true );
On its own, that splashes PHP errors across your live pages, which looks alarming to visitors and leaks server paths to anyone watching. So you almost never use it alone. The safe live-site recipe sends errors to a private file instead of the screen:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );
With this set, errors quietly pile up in /wp-content/debug.log, the default location. Your visitors see nothing. You read the log over SFTP, find the plugin or theme throwing warnings, fix it, then switch all three back to false. One more flag, SCRIPT_DEBUG, forces WordPress to load the full unminified versions of its core CSS and JavaScript, which helps when you’re chasing a front-end glitch.
Can you point the log somewhere outside the public folder? Yes. Pass a full path instead of true, for example define( 'WP_DEBUG_LOG', '/home/you/logs/wp-errors.log' );. That keeps the log off the web entirely, which is the safer choice on any site that handles real traffic.
Performance and Content Settings
This is where wp-config.php stops being plumbing and starts buying you speed and sanity. None of these lines exist by default. You add the ones you need.
define( 'WP_MEMORY_LIMIT', '256M' ); define( 'WP_MAX_MEMORY_LIMIT', '512M' ); define( 'WP_POST_REVISIONS', 5 ); define( 'AUTOSAVE_INTERVAL', 120 ); define( 'EMPTY_TRASH_DAYS', 7 ); define( 'DISABLE_WP_CRON', true );
WP_MEMORY_LIMIT caps how much memory the front end can use. WordPress defaults to 40M for single sites and 64M for multisite, which heavy plugins blow through fast. Raising it to 256M is common. WP_MAX_MEMORY_LIMIT covers admin-only tasks like image processing and defaults to 256M. If you keep hitting memory errors no matter what you set here, your host is the ceiling, and that’s the moment to weigh moving from shared hosting to a VPS with real resources.
The content settings tame database bloat. WP_POST_REVISIONS defaults to true, meaning WordPress stores unlimited copies of every edit. On a busy blog that quietly triples your post table. Capping it at 5 keeps a useful undo history without the bloat. AUTOSAVE_INTERVAL defaults to 60 seconds; doubling it to 120 eases load on a slow server. And EMPTY_TRASH_DAYS defaults to 30, so trashed posts linger for a month unless you shorten it.
Want to kill revisions entirely on a site that never needs them? Set define( 'WP_POST_REVISIONS', false );. Just remember you lose the rollback safety net when you do.
That last line in the block, DISABLE_WP_CRON, is the sleeper speed fix. By default WordPress runs its scheduled tasks (publishing posts, pruning trash, checking updates) on a pseudo-cron that fires whenever someone loads a page. On a busy site it fires far too often; on a quiet one, scheduled posts can publish late because no visitor showed up. Setting it to true stops that, but only do it if you add a real server cron job that hits wp-cron.php on a fixed schedule. Skip that step and your scheduled posts simply stop going out. One related flag: caching plugins like WP Rocket or W3 Total Cache set WP_CACHE to true automatically, so you rarely add it by hand.
Security Hardening Through wp-config.php
A few short lines close some of the most common attack doors in WordPress. Start with the dashboard code editor, which lets anyone with admin access rewrite your theme and plugin PHP straight from the browser. One compromised login and an attacker owns your files. Shut it off:
define( 'DISALLOW_FILE_EDIT', true );
Want to go further on a locked-down site? DISALLOW_FILE_MODS blocks all plugin and theme installs, updates, and deletions from the dashboard. It’s heavy-handed, so reserve it for sites where changes only ever happen through deployment, not the admin panel.
Next, force every login and admin page over HTTPS so passwords and cookies never travel in plain text:
define( 'FORCE_SSL_ADMIN', true );
Two more moves happen outside the file’s contents. First, you can relocate wp-config.php one directory above your WordPress root. WordPress checks the parent folder automatically, and the file then sits outside the public web path, so a server misconfiguration can’t ever serve it as plain text. Second, tighten file permissions. The usual 644 lets other users on a shared server read your file; set it to 600 or 440 so only the owner can. You can also add an .htaccess rule that denies all web requests for the file. Prefer not to manage any of this yourself? Good managed WordPress hosting handles file permissions, SSL, and hardening at the server level for you.
Environment and Modern Constants
Newer WordPress versions added constants that older tutorials skip, and they’re worth knowing in 2026.
WP_ENVIRONMENT_TYPE labels what kind of site this is. It accepts four values: local, development, staging, and production (the default). Plugins read it to behave differently per environment. A handy side effect: when you set it to development, WordPress turns WP_DEBUG on for you automatically.
define( 'WP_ENVIRONMENT_TYPE', 'staging' );
Added in WordPress 6.3, WP_DEVELOPMENT_MODE is a different switch for active building work. It takes core, plugin, theme, all, or an empty string (the default). Theme builders use the theme value so changes to theme.json show up instantly without a cache flush. Leave it empty on any live site; it disables caches you want running in production.
Two veteran constants still earn their place. WP_HOME and WP_SITEURL hardcode your site address. Setting them fixes redirect loops after a domain change and skips a database lookup on every page, a small speed win. They’re the first thing to set when a migration leaves your site pointing at the wrong URL:
define( 'WP_HOME', 'https://example.com' ); define( 'WP_SITEURL', 'https://example.com' );
One last note on updates: WP_AUTO_UPDATE_CORE defaults to 'minor', so your site auto-installs security and maintenance releases but waits for you on big version jumps. That default is sensible for most people. Set it to true for full auto-updates or false to handle everything yourself.
Common wp-config.php Mistakes (and Fast Fixes)
Most wp-config.php disasters trace back to five errors. Recognize them and you’ll fix in minutes what otherwise costs hours.
White screen right after saving. You broke the PHP syntax: a missing quote, comma, or semicolon, or you pasted code below the “stop editing” line. Restore your backup, or fix the exact line. This is why you copied the file first.
“Error establishing a database connection.” One of your four database values is wrong, or the database server is down. Re-check DB_HOST first (it’s the sneakiest), then the username and password against what your host shows in its panel.
Edits do nothing. You’re editing wp-config-sample.php instead of the live wp-config.php, or a caching layer is serving an old page. Confirm the filename, then clear your cache.
Changes vanish after an update. You added lines below the stop-editing comment, and WordPress ignored them. Move your custom defines above that line and they’ll stick.
WordPress asks for FTP credentials. It does this on every update because the server can’t write files directly, so WordPress falls back to begging for a connection. Add define( 'FS_METHOD', 'direct' ); to let it write straight to disk. If that throws permission errors instead, the real fix is correcting file ownership on the server, not this line.
Frequently Asked Questions
Where is the wp-config.php file located?
In your WordPress root directory, the same folder that contains the wp-admin, wp-includes, and wp-content folders. On shared hosting that folder is usually named public_html or www. On a VPS it’s commonly /var/www/html. Reach it through your host’s File Manager or an SFTP client.
Is it safe to edit wp-config.php?
Yes, as long as you back up the file first and use a plain text or code editor, not a word processor. The risk isn’t the file itself, it’s a typo in the PHP, which produces a white screen. Save your edit, reload the site in a new tab to confirm it works, and keep the backup until you’re sure.
What happens if I delete wp-config.php?
Your site stops loading and WordPress redirects to the setup screen, since it can’t find the database credentials. Your content is safe because it lives in the database, not the file. Restore your backup or rebuild the file from wp-config-sample.php with your database details, and the site returns.
How do I fix “Error establishing a database connection” through wp-config.php?
Open the file and check the four database values. DB_HOST is wrong most often, so verify it against your host’s panel (it isn’t always “localhost”). Then confirm DB_NAME, DB_USER, and DB_PASSWORD match your actual database. If all four are right, the database server itself may be down, which is a host issue.
How do I change the WordPress salts, and why would I?
Generate a fresh set at https://api.wordpress.org/secret-key/1.1/salt/ and paste them over the eight existing key and salt lines. The main reason to do it: changing them logs out every logged-in user instantly. That’s the fastest way to kick an attacker off a compromised site, faster than password resets alone.
Does editing wp-config.php log users out?
Only if you change the authentication keys or salts. Those eight values sign the login cookies, so replacing them invalidates every active session at once. Editing other settings, like memory limits or debug flags, leaves logged-in users alone.
Should I move wp-config.php out of the root folder?
It’s a reasonable extra layer. WordPress automatically checks one directory above the root, so moving the file there keeps it outside the public web path entirely. For most sites, correct file permissions (600 or 440) plus an .htaccess deny rule give you nearly the same protection with less fuss.
Can I turn my site into a multisite network from wp-config.php?
Yes. Adding define( 'WP_ALLOW_MULTISITE', true ); unlocks a Network Setup screen under Tools in your dashboard. That’s only step one: WordPress then hands you a second block of constants (like MULTISITE and SUBDOMAIN_INSTALL) to paste in, plus new .htaccess rules. Back up first, because converting to multisite is hard to cleanly undo.
What to Do Next
Open your wp-config.php right now and do three quick checks. Confirm your salts aren’t still the install defaults. Add DISALLOW_FILE_EDIT if it’s missing. And make sure the file permission is 600 or 440, not 644. Those three take five minutes and close real gaps.
If you find yourself raising WP_MEMORY_LIMIT again and again and still hitting walls, the file isn’t your problem, your plan is. That’s the signal to step up from a cramped starter plan to something with real headroom. Just getting started and testing on a throwaway site? A free WordPress host lets you practice these edits with nothing real on the line. Master this one file and you’ve got control over the parts of WordPress most users never touch.