Generate a hardened wp-config.php with fresh security keys, sensible defaults, and the constants most hand-written configs leave out. Salts come straight from the official WordPress.org secret-key service and are unique to your request. Your database password is never asked for.
- wp-config.php holds your database credentials and security keys, which makes it the single most sensitive file in a WordPress install.
- The eight salts must be random and unique per site. Changing them logs everyone out, which is exactly what you want after a breach.
DISALLOW_FILE_EDITremoves the built-in plugin and theme editor, closing an obvious path from a stolen admin login to running code.- Debug output belongs off in production, and the debug log belongs above the web root where nobody can fetch it.
- Never reuse the same salts across staging and production.
What the salts actually do
The eight constants near the top, AUTH_KEY through NONCE_SALT, are what WordPress uses to sign your login cookies. They are not passwords and you never type them. They make a session cookie impossible to forge without knowing the values.
Two consequences follow from that:
- Weak or shared salts undermine the whole session system. A default install with the placeholder text left in place is meaningfully less safe.
- Changing them invalidates every existing session at once. That is the fastest way to kick out an intruder who already has a valid cookie, and it is a required step in any cleanup after a compromise.
This generator fetches them from api.wordpress.org/secret-key/1.1/salt/, the same service WordPress itself uses, so the values are genuinely random rather than produced by a formula. If you only need salts and not a whole config file, our WordPress salt generator creates them entirely in your browser.
The constants worth setting
A default wp-config.php is the bare minimum needed to connect to a database. These are the additions that earn their place.
DISALLOW_FILE_EDIT
WordPress ships with a plugin and theme editor in the dashboard, which means anyone who gets an administrator login can execute arbitrary PHP on your server without needing FTP or a vulnerability. Setting this to true removes those screens. There is very little reason to edit theme files through a browser textarea in the first place.
WP_ENVIRONMENT_TYPE
Tells WordPress whether it is running in local, staging or production. Plugins increasingly read it to decide whether to send real emails, run payments in live mode, or index the site. Setting it correctly prevents a surprising number of staging accidents.
WP_DEBUG and where the log goes
In production, debugging is off. In local and staging the generator turns it on but sends output to a log rather than the screen, and puts that log above the web root:
define( 'WP_DEBUG_LOG', dirname( ABSPATH ) . '/wp-errors.log' );The default location is wp-content/debug.log, which on most hosts is publicly readable. Debug logs contain file paths, database queries, and occasionally credentials. Moving the file out of the web root costs one line.
WP_POST_REVISIONS
Unlimited by default. On a site with long posts and years of editing, revisions can become the largest thing in your database. Capping it at five keeps useful history without the bloat.
FORCE_SSL_ADMIN and WP_MEMORY_LIMIT
The first forces the dashboard over HTTPS so an admin session cannot be sniffed. The second raises PHP’s memory ceiling for WordPress, which quietly resolves a lot of “allowed memory size exhausted” crashes on plugin-heavy sites.
Installing it without locking yourself out
- Copy your existing wp-config.php somewhere safe first. If anything goes wrong you want the original credentials, which is the one thing this generator cannot recreate for you.
- Replace
PUT_YOUR_PASSWORD_HEREwith your real database password. Copy it from the old file rather than retyping it. - Check the database name, user and host match your host’s settings. Some managed hosts do not use
localhost. - Keep your existing table prefix. This is the step that breaks sites. If your tables are
wp_posts, the prefix stayswp_. Changing it on an existing install makes WordPress look for tables that do not exist, and the site behaves as though it is brand new. - Upload it to the WordPress root, alongside
wp-load.php. - Load the site. Expect to be logged out, because the new salts invalidated your session. Log back in.
Changing salts on an existing site is safe and logs out every user including you. Changing the table prefix is not safe and is the one field to leave alone unless you are setting up a fresh install.
Frequently Asked Questions
Is it safe to generate wp-config.php on a website?
This form never asks for your database password, and the generated file leaves a placeholder for you to fill in locally, so the one genuinely secret value never travels anywhere. The salts are fetched fresh from WordPress.org for each request and are not stored. If you would rather generate salts entirely offline, our salt generator runs in your browser with no server involved at all.
What happens when I change the salts?
Every logged-in session becomes invalid immediately, so everyone including you has to log in again. Nothing else is affected: no content, settings or passwords change. That makes rotating salts a cheap and useful thing to do after a suspected breach, after a contractor’s access ends, or if you simply do not know who might still have a live session.
Can I move wp-config.php above the web root?
WordPress will look one directory above the install if the file is not in the root, and plenty of people use that. The honest answer is that the benefit is modest: a correctly configured server never serves .php files as plain text anyway, so the file was not readable to begin with. It also confuses some hosting tools and one-click installers. Worth doing if you control the server and understand the trade, not worth breaking a working setup over.
Should I change my table prefix away from wp_?
On a brand new install, sure, it costs nothing. On an existing site, no. It requires renaming every table and updating serialised values inside the options and usermeta tables, and getting it wrong leaves a site that loads but has lost its settings. The security benefit is small: it only frustrates automated attacks that blindly assume wp_, and does nothing against anything targeted. Time is better spent on updates, strong passwords and two-factor authentication.
More detail in our guide to the wp-config.php file. Related tools: the salt generator, the child theme generator, and the plugin and theme detector.
Browse all our free WordPress tools, all free and none of them asking for an email address.
