What wp-config.php actually controls
It is the first file WordPress loads, before the database connects, before plugins run, before anything renders. That is why it holds your database credentials and why a handful of constants in it decide how your site behaves in ways no plugin can override.
Fill in the form above and it builds the file for you. Everything runs in your browser — nothing you type is uploaded, including the database password.
The database block
Four constants tell WordPress where its content lives. Get one wrong and you get "Error establishing a database connection" — a white page with no further detail.
| Constant | What it is | Where people go wrong |
|---|---|---|
DB_NAME | The database name | Shared hosts often prefix it with your account name (usr123_wp). Copy it exactly from the hosting panel. |
DB_USER | The MySQL user | The user must be granted privileges on that specific database. Creating the user is not enough. |
DB_PASSWORD | That user's password | Passwords with $ or backslashes need care — in double quotes PHP will try to interpret them. |
DB_HOST | The database server | Usually localhost, but managed hosts use a real hostname, a port (host:3306), or a socket path. Never guess this one. |
The table prefix ($table_prefix) is separate from the constants and must match your existing tables. Changing it on a working site does not rename anything — WordPress simply looks for tables that do not exist and the site breaks. Only set a custom prefix on a fresh install.
Security constants worth setting
DISALLOW_FILE_EDIT
Removes the plugin and theme editors from wp-admin. Those editors let anyone with administrator access execute PHP on your server through a browser — which is exactly what an attacker does first after stealing an admin session. You lose nothing by disabling it: editing theme files through that box was never a good idea.
Set this on every production site. There is no meaningful downside.
FORCE_SSL_ADMIN
Forces the login and admin area over HTTPS, so session cookies are never sent in clear text. Only enable it once your certificate genuinely works — if HTTPS is broken, this locks you out of your own admin.
Behind Cloudflare or a load balancer, WordPress may not detect HTTPS and can loop redirects. That needs a proxy header check, not this constant alone.
Authentication keys and salts
Eight random strings that sign your session cookies. If they are missing, duplicated between sites, or left as the placeholder text, sessions become far easier to forge. Replacing them instantly logs every user out — including you, which is precisely why rotating them is the correct response to a suspected compromise.
Debugging without exposing your site
This is the single most common wp-config mistake, and it leaks real information to visitors.
WP_DEBUG turns error reporting on. On its own it prints errors into the page, for everyone — file paths, database structure, plugin internals. On a live site that is an information disclosure.
The safe combination is all three together:
WP_DEBUG→true— collect errorsWP_DEBUG_LOG→true— write them to a fileWP_DEBUG_DISPLAY→false— never show them to visitors
One more step people miss: the default log path is wp-content/debug.log, which is publicly downloadable on most hosts. Either block it in your server config or point the log somewhere above the web root. A debug log is a gift to anyone probing your site.
Memory and cron
WP_MEMORY_LIMIT raises the PHP memory WordPress will use. It cannot exceed what your host allows — if PHP is capped at 128M, setting 512M here changes nothing. Treat repeated exhaustion as a symptom to diagnose, not a number to keep raising; something is usually loading far more than it should.
DISABLE_WP_CRON stops WordPress running scheduled tasks on page loads. On a busy site that is a real performance win, but only if you replace it with a genuine server cron hitting wp-cron.php. Disable it without that and scheduled posts stop publishing, backups stop running, and nothing warns you.
Before you edit the real file
- Download a copy first. A syntax error here takes the entire site down — front end and admin together — and you cannot fix it from wp-admin.
- Add constants above the "stop editing" line. Anything placed after
/* That's all, stop editing! */runs too late to take effect. - Keep the opening
<?phpand add no trailing blank lines. Whitespace after the closing tag causes "headers already sent" warnings. - Change one thing at a time and reload the site between changes, so you know which edit caused a problem.
Related tools
- Server Log Analyzer
Paste the errors your new debug log captures and read what they mean.
- .htaccess Generator
Block public access to debug.log and other files that should not be downloadable.
Frequently asked questions
Where is wp-config.php located?
In the root of your WordPress installation, beside wp-settings.php and the wp-content folder. WordPress will also find it one directory above the web root, which is slightly safer because it cannot then be served over HTTP even if PHP stops executing. If you cannot see it in an FTP client, enable "show hidden files".
Will this tool send my database password anywhere?
No. This generator runs entirely in your browser — the file is assembled in JavaScript on your own machine and nothing is transmitted. You can confirm it by opening your browser's network tab while typing, or by disconnecting from the internet and using the page offline.
Why does my site show "Error establishing a database connection"?
One of the four database values is wrong, or the database server is not reachable. Check them in this order: confirm DB_HOST (managed hosts rarely use localhost), verify the user has privileges on that exact database, then re-enter the password by hand rather than pasting it. If all four are right, the database service itself may be down or out of connections — that is a hosting question, not a WordPress one.
Is it safe to turn on WP_DEBUG on a live site?
Only with WP_DEBUG_DISPLAY set to false and WP_DEBUG_LOG set to true. Otherwise PHP errors are printed into the page for every visitor, exposing file paths and plugin internals. Also make sure the resulting debug.log cannot be downloaded — at its default location, it usually can be.
Can I change the table prefix on an existing site?
Not by editing this value alone. The prefix tells WordPress which tables to read; changing it makes WordPress look for tables that do not exist, and the site breaks immediately. A real prefix change means renaming every table and updating references stored inside the database. Set a custom prefix at install time, or leave it alone.
What happens when I replace the security salts?
Every logged-in session is invalidated, so all users — you included — are signed out and must log in again. Nothing else is affected: no content, settings, or passwords change. Because it kills any session an attacker holds, rotating salts is a standard step after a suspected compromise, ideally alongside a password reset.
Maintained and reviewed
Last reviewed 2026-07-21. This generator runs client-side; the guidance above reflects current WordPress behaviour for configuration constants, debugging, and session salts.