wp-config Generator

Write a working wp-config.php — or refresh the one you already run — without the salts leaving this tab.

Runs on your deviceWordPressWorkingNo account needed

What this tool does

wp-config Generator has two modes, and the input box decides which one you get. Left empty, it writes a complete file from the settings alone: the database block, eight fresh authentication keys and salts, the table prefix, the site behaviour constants, the debugging profile and the wp-settings.php bootstrap line at the end. Paste an existing file in and it rewrites that file instead — credentials replaced, the eight salts rotated, prefix and debug constants brought into line, and every other line you have added over the years left where it was.

The keys and salts are produced by crypto.getRandomValues in your browser, drawn with rejection sampling so no character is favoured over another, from the same character set api.wordpress.org uses — one that deliberately excludes the apostrophe and the backslash, so every value sits safely inside a PHP single-quoted string. Length is yours between 32 and 128 characters, and 64 is what WordPress itself ships. Nothing is fetched and nothing is transmitted: the WordPress config you assemble, the database password you type and the salts all stay in this tab.

What it cannot do is check any of it. No connection is made to MySQL, so a mistyped user or a database that does not exist yet still produces a valid-looking file that WordPress rejects at install, and placing that file on your server is a step you take yourself. Three things are worth knowing before you paste an existing config. Rotating the salts invalidates every login cookie, so everyone signed in — you included — is logged out on the next request. A constant whose value is a function call or otherwise carries a comma or a parenthesis — one built from getenv(), say — is not recognised as something to rewrite in place; a fresh define is appended instead, which PHP then ignores in favour of the original definition higher up the file. And the two tick-boxes only ever add: ticking one writes FORCE_SSL_ADMIN or DISALLOW_FILE_EDIT into the file, but clearing it does not turn an existing definition off, so a config that already forbids the file editor still forbids it until you delete that line yourself.

How to use it

  1. Fill in the database settings. Name, user, password, host and character set. A database name is required. Leave the password field empty and a clearly marked placeholder is written in its place for you to replace before the file goes anywhere.
  2. Set the prefix and the site behaviour. Table prefix, an optional site URL that pins WP_HOME and WP_SITEURL in code rather than the database, environment type, SSL for the admin area, the built-in file editor, memory limit, revisions kept, trash days and core auto-updates. Fields left blank — site URL, memory limit — are simply not written, and in rewrite mode whatever the pasted file already says about them stands.
  3. Choose a debugging profile. Off for a live site. Log to file sends errors to wp-content/debug.log with on-screen display switched off. Log and display is for local work only — it also switches on SCRIPT_DEBUG and SAVEQUERIES.
  4. Paste an existing file, or leave the box empty. Empty produces a whole new document. A pasted file is edited in place, and anything the tool could not find to update is appended under an "Added by OmniKitly" comment near the end. Rewriting is chosen only when the paste opens with a PHP tag and carries at least one define or a $table_prefix line; text that fails that test is quietly ignored and you get a new file instead.
  5. Run, then copy the output. The right-hand pane fills with the finished PHP, and the hint beneath it says in one line which mode ran, how many salts were rotated and how many lines had to be appended. Copy output puts the whole file on the clipboard, ready to paste into wp-config.php at your WordPress root.

Processing & privacy

Runs on your device. Your file is processed directly in this browser.

Common use cases

Setting up an install by hand

wp-config-sample.php ships with the salts reading "put your unique phrase here". Replacing all eight is the step most manual installs skip and the one that actually matters.

Rotating keys after a compromise

New salts void every session cookie at once, which pushes anyone holding a stolen login cookie back to the login form. Change the database and user passwords in the same sitting.

Moving a site to a new host

Rewrite the credentials and host in the config you already run, keep the custom constants you added, and point WP_HOME and WP_SITEURL at the new address before the DNS moves.

Handing a build over to a client

Rotate the salts, disable the theme and plugin editor and turn debugging off in a single pass, so what you leave behind is not the config you developed against.

Questions

Are the salts generated somewhere else and fetched?
No. They come from your browser's cryptographic random number generator in this tab, and building the file makes no network request of any kind. The api.wordpress.org salt service is not called, which is why this still works with the network disconnected.
What happens to my database password?
It is written into the file, because that is what WordPress reads at runtime, and it is escaped for a PHP single-quoted string so apostrophes and backslashes survive intact. It goes nowhere else. Leave the field blank and a placeholder is written instead, and the summary reminds you to replace it.
Will rotating the salts break my site?
It logs everyone out, yourself included, because those keys are what sign login cookies. Posts, plugins, settings and media are untouched. Pick a moment when a forced sign-out costs nothing rather than mid-checkout.
Why was my table prefix rejected?
It has to begin with a letter and use only letters, digits and underscores. A trailing underscore is added for you, so shop becomes shop_. Note that changing the prefix here only changes what the config expects — renaming the tables themselves is what Database Prefix Changer generates the SQL for.
Does it write multisite or Bedrock configuration?
No. It produces a single-site wp-config.php and nothing else. There are no multisite constants among the settings, and no .env output; for Bedrock-style layouts, Salt Key Generator can emit the same keys in .env, WP-CLI or JSON form.
Can I run it again over its own output?
Yes. The rewrite works in place, so a second pass replaces the same constants rather than stacking duplicates, and only the salts change again. A file that is missing some of the eight salt definitions is the exception: instead of patching the gaps, a whole fresh block is appended, and it repeats the keys that were already rotated in place. PHP keeps whichever definition it read first and warns about each repeat, so delete the duplicated lines from the appended block before that file goes live.

Related tools