Editing the wp-config.php file makes most people nervous, and for good reason. It’s one of the only files where a single misplaced character can take your entire site offline, which is exactly why so many WordPress guides tell you to avoid it entirely.
We don’t think that’s the right advice. This file controls your database connection, your site’s URLs, and a handful of settings you’ll genuinely need to adjust at some point, whether that’s fixing an error, migrating to a new host, or tightening up security.
Editing wp-config.php does not have to feel risky. With a clear process and a few simple precautions, you can make changes confidently without turning a small update into a major problem. In this guide, we’ll show you how to edit the file safely, step by step.
TL;DR: Backup your site first, ideally with a backup plugin you can restore in one click, then download a copy of wp-config.php and edit it as plain text. Change only the one value your task needs, add new settings above the “stop editing” line, upload the file back to the same folder, and test your site right away.
Know what’s bringing you here
People reach this file for a handful of recurring reasons, and each one needs the same careful approach. You might recognize yourself in more than one of these:
- A support agent told you to add a line of code, without explaining where that line should go
- You’re migrating your site and need to point WordPress at a new database or domain
- You’re seeing “Error establishing a database connection”, and this file is the likely cause
- You want to tighten security before a hack happens, not after
- You’re troubleshooting something odd, like a memory error or a login that won’t let you back in
Whichever one brought you here, the steps ahead stay the same.
What wp-config.php controls
The wp-config.php file works like a handshake between your WordPress files and your database, the system that stores your posts, pages, and settings. Every time someone visits your site, WordPress opens this file first and reads the database name, username, password, and host it finds inside. Without that handshake, there’s nothing to connect to, and nothing loads.
The file also holds a smaller set of switches that control debugging, your site’s official URL, and how often the editor autosaves your drafts. Most people never need to touch these, but when you do, this file is the only place that adjustment happens.
Don’t confuse wp-config.php with wp-config-sample.php. The sample file is a blank template that ships with every fresh WordPress install, with placeholder text sitting where real values belong. Your live site’s actual file holds your real connection details, so renaming the sample over a working file isn’t a shortcut. It’s one of the fastest ways to take a site offline.
Locate the file
Look for the WordPress root folder, not just any folder with WordPress files in it. You’ll know you’ve found it because three folders always sit together inside it, named:
- wp-admin
- wp-content
- wp-includes.
Your working wp-config.php sits right beside those three, one level up.
On most shared hosting, that root folder is called public_html or even www. Don’t assume this is always true, though. A site installed at example.com/blog keeps its root inside the blog folder instead, so look for those three telltale folders before trusting any single location.
Two doors lead there, and either one works fine:
- Your host’s File Manager, opened directly from the hosting control panel
- FTP or SFTP, connected using the credentials your host provides, with SFTP being the encrypted option worth choosing when it’s offered
📝 Note: If you’re on managed WordPress hosting, check whether your provider expects you to edit this file directly at all. Some platforms generate it automatically or store its values as separate settings, and a manual edit can quietly get overwritten the next time they deploy.
Backup your site before you edit anything
Take a backup before you open the file, not after you’ve made the change. wp-config.php contains your database password in plain text, so treat the file with the same care you’d give any other sensitive credential. Download a copy to a safe local folder, and never paste its real values into a support ticket, screenshot, or forum post.
Match your backup to the size of your change:
- A small constant, like turning on debug logging, just needs your original file and a recent site backup
- A database, URL, or table-prefix change needs the files and the database backed up together
- Anything with wider reach across the site is worth testing on staging site first, a private copy of your site where a mistake costs you nothing
BlogVault’s backup and staging tools give you both of these in one place, so you can test a risky change on a private copy before it ever touches the live site.
📝 Note: A staging copy pushed live still needs a careful look first. Pushed without checking scope, it can overwrite newer orders, comments, or settings that only exist on the live site.See how to move a WordPress staging site to live before pushing changes to production.
Edit wp-config.php in six steps
Follow these steps in order, and resist the urge to skip ahead.
- Download the live file, not a copy sitting in an old backup folder or a different WordPress install on the same hosting account
- Open it in a plain text editor, since PHP is sensitive to punctuation and a word processor can quietly introduce formatting you won’t notice until the site breaks
- Change exactly one value, the one your task actually requires, and nothing else
- Add any new setting above the line that reads
/* That's all, stop editing! Happy blogging. */ - Upload the file back to the exact same folder, checking the destination path before you confirm the overwrite
- Test the site immediately: the homepage, an ordinary post, the login screen, and the dashboard
A blank page, a fatal error, a redirect loop, or the database connection message means something’s wrong. Restore your saved original before you try to diagnose anything further.
Make the most common wp-config.php edits
Not every change here carries the same weight, and knowing the difference tells you how carefully to proceed.
| Edit | What it does | Risk level |
|---|---|---|
| Debug logging | Records errors privately, hides them from visitors | Low |
| Site URL override | Fixes a wrong address without changing the database | Medium |
| Autosave timing | Changes how often the editor saves drafts | Low |
| Database credentials | The connection details WordPress uses to reach your database | High |
| Authentication keys and salts | Signs every logged-in user out at once | Medium |
| Table prefix on a live site | Requires matching changes across your database tables | High |
A handful of these come up often enough to walk through properly.
Turn on debug logging without exposing errors to visitors. This keeps errors in a private log instead of showing them on the page:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
Place these lines above the ‘stop editing’ marker, following this guide to debug WordPress safely if you need help finding the cause of an error. Public error display can reveal file paths and other details you’d rather keep private, so turn debugging back off once you’ve found what you needed.
Fix a URL temporarily using WP_HOME and WP_SITEURL, which override the address WordPress uses without changing the value stored in your database:
php
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );
These two values need to match your site’s real scheme, host, and subdirectory exactly. Remove the override once the underlying setting is properly corrected.
Adjust the autosave interval, which defaults to 60 seconds:
define( 'AUTOSAVE_INTERVAL', 300 );
That example sets it to five minutes instead. Test it on staging first if losing unsaved work would genuinely cost you something.
Correct database connection values by getting DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST exactly right. A typo in any one of them is often the direct cause of the database connection error, especially right after a migration. Get the precise values from your host, and never copy a real password anywhere you might later share it. If you need to back up the database separately before making changes, follow this guide to back up your WordPress database.
Replace authentication keys and salts when you suspect a genuine credential issue. These eight values sign every login cookie, so replacing them signs every logged-in user out immediately. Generate fresh values from a trusted source rather than typing your own.
📝 Note: Changing the table prefix on a live site isn’t a quick security win. It requires renaming actual database tables and updating every reference to them, so give it its own backup and testing plan.
Recover from a failed edit
The moment something fails after an upload, resist the urge to keep changing lines. Replace the edited file with your saved original using File Manager or FTP, or use your host’s backup restore if you have one. Choose the smallest restore that returns the site to its last working state, using this guide to recover a WordPress website if you need help restoring it.
If restoring the file alone doesn’t fix it, the change may have reached your database too. Ask your host for the PHP error log, since it usually points directly at the cause when the failure is a syntax error, a fatal error, or a server configuration issue.
A syntax error simply means PHP couldn’t read the file as written. The usual causes are a missing semicolon, a quote that never closes, or a bracket that doesn’t match its pair. Compare your edited copy against the original line by line before you try uploading again.
FAQs
Where is wp-config.php located?
It sits in your WordPress installation’s root folder, the same level as wp-admin, wp-content, and wp-includes. public_html is a common example on shared hosting, but your site’s actual folder structure may place it somewhere else.
Can I edit wp-config.php from the WordPress dashboard?
Usually not. WordPress doesn’t provide a built-in dashboard editor for this file, so you’ll need your host’s File Manager or an FTP/SFTP client, unless your hosting provider documents its own method.
What should I do before editing it?
Download and keep the current file, and take a full site backup when the change is more than a single low-risk constant. Test anything touching URLs, the database, or table names on staging first.
Where do I put a new setting?
Above the line that reads /* That's all, stop editing! Happy blogging. */. Anything added below that point can load too late to take effect.
What if I make a mistake and the site breaks?
Restore your saved original file first, then check the PHP or server error log to understand what went wrong. Keep public error display turned off while you’re diagnosing a live site.
Conclusion
Editing wp-config.php is one of those tasks that feels far riskier than it actually is, right up until you’ve done it once the careful way. Whatever brought you to this file, whether it was a support ticket, a migration, an error message, or a security checklist, you now have a repeatable process instead of a guessing game.
Backup before you start, download the live file rather than a stray copy, change exactly one value, and test the site before you consider the job done. Keep that original file within reach until every page passes, because the fastest way out of a bad edit is one you were already prepared for. Do this once with that discipline, and every future edit to this file will feel like routine maintenance instead of a risk.
Akshat is the founder and CEO of BlogVault, MalCare, and WP Remote.
