Installing WordPress the classic way means finding hosting, creating a database, and uploading files before you can even log in. WordPress Playground skips all of that. You open a browser tab, wait a few seconds, and a complete WordPress site boots up in front of you. No server, no database, no signup form. 🚀
The trick behind it: PHP, the programming language WordPress is written in, gets compiled to WebAssembly (a format your browser can run directly), and SQLite stands in for the usual MySQL database. The whole thing runs on your device, and it’s an official WordPress.org project, free for anyone to use.
This guide explains what Playground actually is, walks through five practical ways everyday site owners can use it today, and then gets honest about the limitations, because there are a few you should know before you rely on it for anything serious.
Let’s jump right in!
What is WordPress Playground, exactly?
Head to playground.wordpress.net and you’ll land inside a working WordPress site within seconds. Everything happens locally in your browser tab: the PHP engine, the database, the files. Nothing touches a server you pay for, and nothing you do in there can hurt a real website.
Under the hood, the project compiles PHP versions 7.0 through 8.4 to WebAssembly, pairs them with SQLite, and stores your site’s files in your browser’s storage. It’s a real WordPress, not a simulator or a screenshot tour, so themes, plugins, and settings behave the way they would on a regular install.
This isn’t a random side project, either. Playground is an official WordPress.org effort, started and led by core committer Adam Zieliński with a small team sponsored by Automattic, and it’s open to all contributors on GitHub. The team posts updates on the Make WordPress Playground blog. One thing to keep in mind: the project calls itself experimental and warns it “may break or change without a warning.” Fair enough, and worth remembering for the limitations section below.
💡 PRO TIP: Treat every Playground session as disposable by default. If you end up building something you want to keep, you can export the whole site as a ZIP file before closing the tab.
Beyond the quick browser demo, the toolbox also covers multi-site management, file editing, database and log inspection, and importing complete sites. Most of that matters more to developers than to casual testers, but it’s good to know the ceiling is high.
1. Test a plugin or theme safely before it touches your site
This is the use case most site owners will love immediately. Playground accepts URL parameters that pre-install plugins and themes for you, so you can try software in a sandbox instead of gambling on your live site. 🧪
Here’s a real example. Opening https://playground.wordpress.net/?plugin=coblocks boots a fresh WordPress site with the CoBlocks plugin already installed and active. Swap the slug to test something else, add several plugin parameters to check how plugins interact, or use ?theme= the same way to preview a theme. The Query API documentation lists the full set of options.
Why bother? Because “will this plugin break my layout?” is a much nicer question to answer in a throwaway tab than on the site your visitors see. Test first, install second. 👍
2. Learn wp-admin without breaking anything
One of the project’s stated goals is “Learning WordPress Through Exploration,” and it delivers. If you’re new to WordPress, Playground gives you the full admin dashboard, menus, settings, the block editor, all of it, in an environment where mistakes cost exactly nothing.
Poke around Settings, publish a test post, install a random theme, delete things on purpose just to see what happens. When you’re done, close the tab and the evidence disappears. It’s the driver-ed car of WordPress: same controls, no consequences. 😅
3. Spin up an instant demo for clients or readers
Ever clicked a “Live Preview” button on a plugin’s page in the WordPress.org directory? That’s Playground doing the work. Those buttons launch a blueprint (a small JSON recipe that tells Playground how to set up the site) so you can try the plugin before downloading it.
You can use the same trick yourself. Freelancers can send a client a link to a pre-configured demo instead of a slide deck. Support forums, tutorials, and documentation can link to a ready-made example site rather than describing one. A demo that loads in seconds beats a screenshot every time. ⚡
The format itself keeps improving, too. GitHub integration and a next-generation blueprint format are both in active development, so expect demos to get easier to share, not harder.
4. Reproduce a bug so support can actually see it
“It works on my machine” is the oldest argument in tech support. Playground settles it. Because a blueprint can recreate a specific site state (which plugins are installed, whether you’re logged in, what code ran), you can hand a support team the exact environment where your problem happens.
Blueprints are plain JSON files with a list of steps. Available steps include installPlugin, login, and runPHP, plus a WP-CLI step for command-line tasks (with the caveat that it doesn’t support every WP-CLI command). A minimal blueprint looks like this:
{
"steps": [
{ "step": "login" }
]
}That one-step recipe opens a Playground site already logged into wp-admin. Stack more steps and you can recreate quite specific setups, then share the blueprint with whoever is helping you debug. No more writing “so first I installed X, then I clicked Y” essays. 🙌
5. Develop locally without Docker or a server stack
Local WordPress development traditionally means Docker, or a stack like XAMPP (here’s how the XAMPP route works if you want the classic setup). Playground offers a lighter path. The official @wp-playground/cli tool runs a local Playground server with a single command, npx @wp-playground/cli server --auto-mount, as long as you have Node.js installed. Note that the older wp-now tool was officially deprecated in June 2026 in favor of this CLI.
Prefer a point-and-click app? Studio is Automattic’s free desktop app powered by Playground, with extras like preview sites and syncing to WordPress.com or Pressable hosting. There’s also an official Playground extension for Visual Studio Code if your editor is where you live. 🛠️
The limitations you should know about ⚠️
Playground is genuinely useful, but the magic has edges. Here’s the honest list:
- Networking is partial. Outbound requests from the browser go through a limited CORS proxy (a middleman that fetches external data on the site’s behalf), and extending it to all cross-origin requests is still an open issue. Features that need to call external APIs may simply not work.
- Don’t count on email. Sending real email requires outbound connections that the current networking layer doesn’t reliably allow, and the official docs don’t document working email. Password resets and contact forms are live-site things.
- Browser storage can vanish. Sites kept in browser storage can be evicted by private browsing modes or storage pressure. There are three storage modes (Autosaved, which keeps up to 5 recent autosaves; Saved, for permanent browser storage or a local directory; Temporary, discarded on close), but exporting a ZIP is the recommended portable backup.
- It’s experimental. The project itself warns it “may break or change without a warning.” Don’t build a workflow on it that you can’t redo.
- Heavy plugins take patience. Official expectations: a fresh WordPress loads in about 5 to 10 seconds, sites with small plugins take 10 to 20 seconds, and WooCommerce-class plugins can take 30 to 60 seconds. The engine itself is a 15 to 30MB download.
- Small iframe quirks. Links targeting the top window can reload the host page, and JavaScript popups from inside Playground may not display.
None of these are dealbreakers for the five uses above. They just define the boundary between “brilliant sandbox” and “actual website.”
When you still need real hosting
Let’s be clear about what Playground is not. It’s not a hosting replacement, because your site lives in your browser instead of serving real visitors. It’s not a staging replacement either, since a staging site’s whole job is to match your live server’s configuration, and your browser is not your server. Email, cron jobs, real traffic, payment gateways: all of that still needs an actual host.
So the healthy pattern looks like this: use Playground for quick, disposable experiments and learning, use a proper WordPress staging site when you need to test changes against your real setup, and use real hosting for anything the world needs to see. Each tool has its lane, and Playground’s lane happens to be the one you were missing. 🏁
Have you tried WordPress Playground yet, and what did you use it for? Let us know in the comments section below!
FREE GUIDE
4 Essential Steps to Speed Up Your WordPress Website
Follow the simple steps in our 4-part mini series and reduce your loading times by 50-80%. 🚀
