How to Install WordPress on a Local Host (2026 Guide)

The fastest way to install WordPress on localhost in 2026 is a one-click local app: Studio or Local both set up PHP, MySQL and WordPress for you in under two minutes, with no configuration. The manual XAMPP route still works and teaches you what is actually happening, but it is slower and its bundled software is now noticeably out of date.

Why run WordPress locally at all

Four good reasons, in rough order of how often they come up.

Theme and plugin development. You need to break things, read PHP errors, and reload constantly. Doing that on a live server is slow and public.

Safe testing. Before a major WordPress update, a new page builder, or a plugin you have not used before, try it on a copy. This is the single best habit you can build. It turns “my site is down” into “that plugin does not work, moving on”.

Learning. A local install costs nothing, needs no domain, and cannot be hacked or indexed. You can delete it and start over as many times as you like.

Building before you have hosting. Design the whole site locally, get the client to approve it, then buy hosting and push it live in one go. You are not paying for a server while you work, and there is no half-finished site sitting on a public URL.

Your options in 2026, compared honestly

All seven are alive and free to start with in July 2026. My picks: Studio if you just want a site now, Local if you work with clients and need shareable links, wp-env if you are writing a plugin, XAMPP only if you specifically want to learn the plumbing.

The easy route: install WordPress locally with Studio

Studio is free, open source, and runs on macOS (Apple Silicon and Intel), Windows (x86 and ARM) and Linux. There is also an npm-installable CLI.

1. Download and install Studio, then open it.
2. Click Add site in the lower-left corner.
3. Choose Build a new site, then Empty site.
4. Type a site name. That is the only required field.
5. Optionally open Advanced settings to pick where the files live on disk, which WordPress version to install, which PHP version to run, and a custom domain. Custom domains have to end in .local.
6. Click Add site and confirm with your system password.

When it finishes, Open site loads the front end and WP admin drops you into the dashboard already logged in. No password to remember. Without a custom domain, sites are served from localhost on a port Studio assigns.

What you get beyond the basics: two-way sync with a production or staging site on WordPress.com or Pressable, including selective sync of individual plugins or themes; hosted preview sites so a client can look at your work without you deploying anything, with up to ten free at once; Blueprints for repeatable site templates; and phpMyAdmin, Xdebug and the debug log built in.

Or use Local, if you are on WP Engine or Flywheel

Local needs 4GB of RAM, 1.5GB of disk, and macOS 12 or later, Windows 10 64-bit or 11, or a Debian-based Linux. Install it, create a site from the app, and you get one-click SSL, root SSH and WP-CLI access, MagicSync for selective file syncing, Cloud Backups to Google Drive or Dropbox, and Live Links for sharing a local site over a public URL. If your host is WP Engine or Flywheel, its Connect feature pushes and pulls entire sites, which is the fastest local-to-live workflow there is.

Or wp-env, if you are building a plugin

npm -g i @wordpress/env
cd my-plugin
wp-env start
wp-env run cli wp plugin list
wp-env stop

It reads your plugin folder, mounts it into a container, and serves the development site at http://localhost:8888 with a separate test environment on port 8889. Log in with admin / password. You need Docker, Node and git installed first.

The manual route: XAMPP step by step

Be aware of what you are signing up for. The newest XAMPP bundles for Windows and Linux are 8.0.30, 8.1.25 and 8.2.12, all released in November 2023, with Apache 2.4.58 and MariaDB 10.4.32. The macOS builds are older still. WordPress currently recommends PHP 8.3 or greater and MariaDB 10.11 or MySQL 8.0, so XAMPP puts you a step behind on both counts. It works fine for learning and testing. It is not a good way to mirror a modern production server.

Step 1: Install XAMPP

Download the installer for your PHP version from apachefriends.org and run it. On Windows, install to the default C:\xampp rather than inside Program Files, otherwise Windows permissions will fight you every time you edit a file. You can safely untick the components you do not need, but keep Apache, MySQL and phpMyAdmin.

Step 2: Start Apache and MySQL

Open the XAMPP Control Panel and click Start next to Apache, then next to MySQL. Both should turn green and show port numbers. Visit http://localhost and you should see the XAMPP dashboard. If Apache refuses to start, skip to the port 80 section in troubleshooting.

Step 3: Create the database

Go to http://localhost/phpmyadmin, click Databases, type a name such as wordpress_local, choose the utf8mb4_unicode_ci collation, and click Create. You do not need to create a user; you will use root.

Step 4: Drop WordPress into htdocs

Download the latest WordPress from wordpress.org and extract it into a subfolder of C:\xampp\htdocs, for example C:\xampp\htdocs\mysite. On macOS the equivalent is /Applications/XAMPP/htdocs. Make sure you copy the contents of the extracted wordpress folder, not the folder itself, unless you want the URL to end in /mysite/wordpress/.

Step 5: Run the five-minute install

Visit http://localhost/mysite. Pick your language, then fill in the database screen:

• Database Name: wordpress_local
• Username: root
• Password: leave it empty
• Database Host: localhost
• Table Prefix: wp_

Then set a site title, an admin username and password, and an email address. Done. If WordPress cannot write wp-config.php itself, it shows you the file contents to paste in manually:

define( 'DB_NAME', 'wordpress_local' );
define( 'DB_USER', 'root' );
define( 'DB_PASSWORD', '' );
define( 'DB_HOST', 'localhost' );

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', true );

$table_prefix = 'wp_';

Turning WP_DEBUG on is the whole point of working locally: you see the errors instead of a white screen. If you later hit a plugin that breaks the dashboard, the same fix applies as on a live server, which our guide to disabling a WordPress plugin from cPanel covers in full.

Local HTTPS

Studio and Local both handle this for you. Studio issues certificates for .local domains during site creation, and Local advertises one-click SSL. That matters more than it used to, because features like the block editor’s media handling and any third-party script that insists on a secure context behave differently over plain HTTP.

On XAMPP you get a self-signed certificate at https://localhost that every browser will warn about. The clean fix is mkcert, which installs a local certificate authority into your system trust store and issues certificates your browser accepts without complaint. Generate a cert for your local hostname, point Apache’s SSL virtual host at it, and restart Apache.

Email does not work locally, and that is normal

WordPress sends mail with PHP’s mail() function, which hands the message to a local mail transfer agent. Your laptop does not have one. So password resets, form notifications and WooCommerce order emails all vanish without an error message.

The answer is a mail catcher: a fake SMTP server that accepts everything and shows it in a web inbox instead of delivering it. Local ships Mailpit and exposes it at Tools > Mailpit > Open Mailpit, so a password reset email you trigger locally appears there within a second. DevKinsta has its own built-in email management and SMTP testing.

On XAMPP, run Mailpit yourself. It listens for SMTP on port 1025 and serves its web inbox on port 8025 by default, so install an SMTP plugin in WordPress, point it at 127.0.0.1 port 1025 with no authentication and no encryption, and read your mail at http://localhost:8025.

How to push a local site live

Two routes. Pick based on how much you trust plugins.

The plugin route

If your local app has a built-in deploy path, use it: Local’s Connect pushes to WP Engine and Flywheel, and Studio syncs to WordPress.com and Pressable. Both handle URLs and serialized data correctly.

Otherwise use a migration plugin such as All-in-One WP Migration, Duplicator or WP Migrate. The pattern is the same in all of them: export a single archive locally, install a fresh WordPress on your host, install the same plugin, import the archive. Watch the file size limit on shared hosting, which is the usual point of failure.

The manual route

1. Export the local database: wp db export local.sql, or the Export tab in phpMyAdmin.
2. Upload your files to the live server over SFTP, or zip wp-content and extract it there with cPanel’s File Manager.
3. Create a database and user on the host, then import local.sql into it.
4. Update wp-config.php on the server with the live DB_NAME, DB_USER, DB_PASSWORD and DB_HOST, and remove the debug constants.
5. Rewrite the URLs, then flush permalinks by re-saving Settings, Permalinks.

wp search-replace 'http://localhost/mysite' 'https://example.com' --dry-run
wp search-replace 'http://localhost/mysite' 'https://example.com' --skip-columns=guid

Use wp search-replace, not a SQL find and replace. It unserializes values, swaps the string, and re-serializes with correct length prefixes. A raw SQL REPLACE() silently corrupts every serialized option whose length changes, which is how widgets and theme settings mysteriously reset after a migration. Our guide to running a database query in WordPress goes into why, and where WordPress plugin settings are stored explains which rows are at risk.

One more step people forget: your analytics were probably not recording anything useful locally. Once the site is live, check the tracking actually fires, using either Google Analytics on WordPress or Google Tag Manager on WordPress.

Troubleshooting

Apache will not start: port 80 is already in use

Something else owns the port. On Windows the usual culprits are IIS and the World Wide Web Publishing Service, VMware, or Windows’ own HTTP service. Note that the old advice about Skype grabbing port 80 no longer applies at all: consumer Skype was retired in May 2025.

Find the process, then decide:

netstat -ano | findstr :80
tasklist /fi "pid eq 1234"

Either stop that service, or move Apache. To move it, edit httpd.conf from the control panel’s Config button, change Listen 80 to Listen 8080 and ServerName localhost:80 to ServerName localhost:8080, restart, and use http://localhost:8080/mysite. Port 443 conflicts are usually VMware, and the same approach applies in httpd-ssl.conf.

“Error establishing a database connection”

Work through it in this order. Is MySQL actually running and green in the control panel? Does DB_NAME exactly match the database you created, including case? Have you set a root password at some point and forgotten? Is another MySQL or MariaDB service already holding port 3306, which happens a lot on machines that once ran a different stack? If localhost fails, try 127.0.0.1 as the host, which forces TCP instead of a socket.

localhost keeps redirecting to the live domain

You imported a production database and the siteurl and home options still point at the live URL, so WordPress redirects you away before it renders anything. Override them in wp-config.php, which wins over the database:

define( 'WP_HOME', 'http://localhost/mysite' );
define( 'WP_SITEURL', 'http://localhost/mysite' );

That gets you back in. Then run wp search-replace to fix the URLs properly and remove the two constants. Clear your browser cache while you are at it, because a 301 redirect gets cached aggressively and will keep bouncing you even after the fix.

Mixed content warnings

The page is loading over HTTPS but images, scripts or stylesheets are still requested over HTTP, so the browser blocks them and the padlock disappears. Set siteurl and home to the https:// version, then search-replace http://yoursite to https://yoursite across the database. Hardcoded HTTP URLs inside page builder content are the usual stragglers; the browser console lists every blocked request by URL.

Everything is painfully slow on Windows

Add your local site directory to your antivirus exclusion list. Real-time scanning on a folder that PHP reads thousands of files from is a common and easily fixed cause of multi-second page loads.

Frequently asked questions

Is it free to install WordPress on localhost?

Yes, completely. WordPress is free, and Studio, Local, DevKinsta, XAMPP, MAMP and wp-env all have free versions. You need no domain and no hosting. The only paid consideration is Docker Desktop, which requires a subscription for larger companies, and that only matters if you choose a Docker-based tool.

Can other people see my local WordPress site?

Not by default. It is served on your own machine and is unreachable from the internet, which is exactly why a blank database password is tolerable. If you need to show someone, use a sharing feature built for it, such as Local’s Live Links or Studio’s preview sites, rather than opening ports on your router.

Which is better, Local or XAMPP?

Local, for WordPress specifically. It creates a working site in under two minutes with modern PHP, SSL and a mail catcher included, all of which you configure by hand in XAMPP. XAMPP is the better choice if you want to run non-WordPress PHP projects alongside, or if you specifically want to learn how Apache, MySQL and PHP fit together.

Do I need to know how to use the command line?

No. Studio, Local, DevKinsta and MAMP are entirely graphical, and the XAMPP route only needs a browser and a file manager. Docker and wp-env are command line only, so skip those if you would rather not. WP-CLI is worth learning eventually because it makes migrations far easier, but nothing here requires it.

How do I move an existing live site down to my computer?

Export the live database and download wp-content, then import both into a fresh local install and run wp search-replace from the live URL to your local one. Local’s Connect and Studio’s sync do the whole thing in one click if your host is supported, and a migration plugin will do it on any host.

Which PHP version should I pick locally?

Match your live server, then test one version above it. WordPress recommends PHP 8.3 or greater, and running on an end-of-life version such as 7.4 exposes you to known vulnerabilities. If your local tool cannot offer 8.3 or newer, that is a real limitation worth factoring into your choice.

Wrapping up

Install Studio or Local, click Add site, and you have a working local WordPress install before you finish reading this sentence. In 2026 there is no good reason to configure Apache, MySQL and PHP by hand unless you actively want to learn how they fit together, and if that is what you want, XAMPP is still a perfectly good classroom.

Whichever route you take, do two things. Turn WP_DEBUG on, because seeing the actual error is the entire advantage of working locally. And set up a mail catcher before you test anything that sends email, so you find out your form works instead of wondering why nothing arrived. If you are comparing WordPress with other platforms while you are here, our walkthrough on creating a Joomla website covers the same ground on the other side of the fence. The primary sources for the versions quoted above are the WordPress requirements page, the XAMPP download page and the wp-env documentation.