wp-config.php is the file that tells WordPress where its database is and how to behave. It is also the file people are most nervous about touching, because a mistake in it shows a completely blank page with no explanation.
Fill in your details below and copy the finished file.
Everything on this page happens inside your browser. Nothing is sent to any server, including ours. Your database password never leaves this machine.
Save as wp-config.php in the same folder as wp-admin and wp-content. Back up your existing one first, because the database details in it are the only copy you may have.
About typing your database password in here
You should be suspicious of any website asking for that. So here is exactly what happens.
This tool has no server component at all. The whole thing is JavaScript running inside your browser, on your machine. There is nothing for it to send anything to. You can prove it: open your browser’s developer tools, go to the Network tab, and type into the boxes. Nothing leaves.
The salt keys are made the same way, using the random generator built into your browser rather than fetched from anywhere.
If you would still rather not, leave the password box empty, copy the file, and type the password in yourself afterwards. Everything else still works.
Finding your database details
If WordPress is already installed, the easiest source is your current wp-config.php. Open it in your hosting File Manager and the first few lines have everything.
For a fresh install, you create the database first in your hosting panel, usually under MySQL Databases. It gives you a name, a user and a password when you do.
The host field
localhost is right on the overwhelming majority of shared hosting, which is why it is filled in already.
Some hosts use a separate database server and give you an address like mysql.yourhost.com or an IP. If yours does, they will have told you. If your site cannot connect and everything else looks right, this field is the usual culprit.
The table prefix
Almost always wp_. If WordPress is already installed, this must match exactly what is there now. Change it and WordPress looks for tables that do not exist, decides the site is not installed, and offers to set up a brand new one. Your content is still safe in the database, but it is an alarming few minutes.
Only pick something different for a brand new install.
What each setting actually does
There are dozens of constants you can put in this file. Most guides list all of them. These are the ones that earn their place.
Salt keys
Eight long random strings that sign the cookies keeping people logged in.
The useful thing about them: replacing the keys signs out every session everywhere, instantly. That is the correct response if you think somebody else got into your site, because changing the password alone does not remove anyone already logged in. Their cookie keeps working.
Fresh ones are generated every time this page loads, and the New salt keys button makes another set. You will be signed out of your own site when you use them, which is expected.
Turning off the file editor
DISALLOW_FILE_EDIT removes the built-in editor under Appearance and Plugins, the one that lets you edit theme and plugin code from inside wp-admin.
Worth doing on every live site for two reasons. Anyone who gets into your admin can otherwise run any code they like, instantly, with no file access needed. And it removes the temptation to edit a live theme file with no undo, which is how a lot of sites go down.
Force HTTPS in the admin
FORCE_SSL_ADMIN means your login and admin pages always use HTTPS, so your password is never sent in the clear.
One warning: only turn this on if you actually have a working certificate. Without one you get a redirect loop and cannot reach wp-admin at all. If that happens, remove the line through your file manager.
Memory limit
WordPress defaults to 40MB, which modern plugins outgrow easily. Running out shows as a white screen or “Allowed memory size exhausted”.
Be aware this asks rather than commands. Your host sets a hard ceiling in PHP, and WordPress cannot exceed it. If raising this changes nothing, the limit is above your plan’s allowance and only your host can lift it.
Limiting revisions
WordPress keeps every draft of every post forever by default. On a site with a few hundred posts that quietly becomes thousands of rows, and it is one of the most common reasons a database grows far larger than the content justifies.
Five is plenty for almost everyone. Note it only affects revisions made from now on, so an existing bloated database needs cleaning separately.
Disabling WP-Cron
Left alone, WordPress checks for scheduled jobs on page loads, which means a quiet site runs them late and a busy one runs the check far too often.
Only tick this if you will set up a real cron job. Turning it off without a replacement means scheduled posts never publish, backups never run and nothing tells you. That is a genuinely bad surprise, and the tool warns you when you tick it.
The replacement is one line in your host’s cron panel, run every fifteen minutes:
wget -q -O - https://yoursite.com/wp-cron.php?doing_wp_cronDebug settings
These change based on whether you said the site is live, staging or local, which is why that question is there.
On a live site debugging is off. On staging and local it writes errors to a log file at wp-content/debug.log but never displays them on screen.
That distinction matters more than it looks. Errors printed into the page corrupt the responses WordPress sends back to itself, which breaks the block editor and anything using AJAX. The symptoms look like completely unrelated bugs, and people lose hours to it. Log, never display.
Installing the file
- Open your hosting File Manager and go to
public_html, where you can see thewp-adminandwp-contentfolders. - Download your existing
wp-config.phpfirst. It holds database details that may exist nowhere else. - Replace the contents with what the tool produced, or upload the new file over it.
- Load your site. It should look exactly as before.
You will be signed out, because the salt keys changed. That is expected, and it is the one visible sign the new file took effect.
When it goes wrong
Error establishing a database connection
One of the four database values is wrong. Compare them character by character with the file you downloaded, and check the password for a typo, since it is the one you cannot see anywhere else to confirm.
If they look identical, try the host field. Some hosts do not use localhost.
A completely blank white page
A PHP syntax error, which usually means something got mangled in copying. The two things to check are that the file starts with <?php on the very first line with nothing at all before it, not even a blank line, and that nothing was cut off the end.
Put back the copy you downloaded and try again.
WordPress offers to install itself
The table prefix does not match your existing tables. Do not click through that installer. Fix the prefix to match what your database actually has and reload.
To check, open phpMyAdmin and look at the table names. Whatever comes before posts is your prefix.
Redirect loop on wp-admin
FORCE_SSL_ADMIN is on but there is no working certificate. Remove that line through your file manager and the loop stops immediately.
Questions people ask
Can I keep my old file and just add lines?
Yes, and it is often the safer choice on an existing site. Copy just the settings you want from the output and paste them above the line that says stop editing. Anything after that line is ignored.
Will changing the salt keys lose anything?
Only the current login sessions. No content, no settings, no users. Everyone signs in again and carries on.
Should wp-config.php be outside the public folder?
WordPress does support moving it one level up, and you will see this advised as a security measure. It is worth less than it sounds, because the file is already never served as text, and it breaks some backup and migration tools that expect it where it belongs.
Blocking direct access to it in your server config gets the same protection with none of the disruption. Our htaccess generator has that under Hide sensitive files.
What about all the other constants I have seen?
Most are either obsolete, better handled elsewhere, or copied between blog posts without anyone checking whether they still do anything. The settings offered here are the ones with a real effect on a normal site.