How to View a WordPress Site Locally

Direct answer: run WordPress inside a local development environment, then open the local URL that environment provides in your browser. The URL depends on the tool and its configuration. http://localhost:8888/ is an example used by wp-env, not a universal WordPress address.

A local copy lets you test themes, plugins, content changes, and upgrades without interrupting the live site. It does not automatically sync with production, so treat importing, exporting, and deployment as separate steps.

Choose a local WordPress method

Method	Best for	What you open	Trade-off
WordPress Studio	A managed desktop workflow	The site URL shown by Studio	Less infrastructure control
Local	Desktop users who want guided setup	The URL shown by Local	Tool-specific configuration
WordPress Playground	A quick browser trial or disposable environment	The public Playground instance or your local Playground tool	Persistent, production-like setups need additional configuration
`wp-env`	Block, theme, and plugin development	Often `http://localhost:8888/`	Requires Node.js, Docker, and command-line comfort
Docker, MAMP, XAMPP, or VVV	Control over the web server and database	The host and port you configure	More setup and troubleshooting
Manual install	Learning or controlling every component	The local URL configured in your web server	You configure files, PHP, the database, and the web root yourself

The WordPress Theme Handbook lists Studio, @wordpress/env, Docker, Local, MAMP, XAMPP, and Varying Vagrant Vagrants (VVV) as local development options. Playground also supports browser, command-line, and Visual Studio Code workflows. Pick based on setup effort, desktop versus browser or CLI workflow, required control, and whether you are learning, testing, or building a theme or plugin.

Option 1: Start with a managed local environment

Install a current WordPress local tool such as WordPress Studio or Local.
Create a new site and choose the PHP, web-server, and WordPress versions offered by the tool.
Wait for the tool to finish creating the files and database.
Click its Open site, View site, or equivalent action.
Copy the displayed local URL. It may use localhost, a custom local domain, or a port selected by the tool.
Open that URL in your browser. Use the tool’s admin link for the dashboard.

Do not assume that credentials or ports from another tutorial apply to your installation. Use the values shown by the tool. If you are working from an existing live site, import a backup through the tool’s documented workflow and keep the local copy separate from production.

Option 2: Try WordPress Playground

WordPress Playground starts WordPress in a browser and also documents local development through its CLI and Visual Studio Code extension. It is useful for quickly trying WordPress, checking a plugin, or demonstrating a workflow without first assembling a traditional PHP and database stack.

Open the public Playground instance or follow the Playground handbook for the CLI or editor workflow you need.
Install or activate the theme and plugins required for your experiment.
Use the Playground-provided address to view the site.
Export or persist the environment according to the current Playground instructions if you need to keep your changes.

Playground behavior and available integrations can change, so follow the current handbook for persistent storage, networking, and editor-specific instructions.

Option 3: Use `wp-env`

wp-env runs WordPress in a development environment suited to plugin, theme, and block work. The WordPress Developer Blog’s example installs @wordpress/env, starts it with wp-env start, and reports the development site at http://localhost:8888/.

Prerequisites

Node.js and npm
Docker Desktop (running)
A project directory containing your plugin, theme, or block code

Commands

mkdir my-wp-project
cd my-wp-project
npm init -y
npm install --save-dev @wordpress/env
npx wp-env start

When startup completes, open the URL printed by the command. In the documented example it is http://localhost:8888/. Your environment may report a different address or port.

Stop and restart

npx wp-env stop
npx wp-env start

If you need to remove the environment, read the current wp-env documentation first because cleanup commands can remove local data.

Option 4: Install WordPress manually

A manual installation needs four pieces:

WordPress core files placed in your web document root.
A web server and PHP configured to serve those files.
A MySQL or MariaDB database and its connection details.
A local URL mapped to the document root.

Manual sequence

Install or start a local stack such as Apache or Nginx with PHP and MySQL or MariaDB.
Download WordPress from wordpress.org.
Extract the files into the configured document root.
Create an empty database and database user in your local database tool.
Open the local URL for that document root.
Enter the database name, username, password, host, and table prefix requested by the installer.
Create the local administrator account.
Sign in at the local dashboard and verify that the site loads.

Database names, usernames, passwords, hosts, ports, and URLs vary by operating system and stack. Treat every value in a tutorial as an example unless your environment shows the same value.

Viewing an existing live site locally

To work on an existing site, obtain a database export and a copy of wp-content (especially themes, plugins, and uploads), then import them into your chosen local environment. Follow that tool’s migration instructions to update the site’s home and site URLs. Check the result before editing:

Images and links point to the local host.
The dashboard opens without redirecting to production.
Required plugins are installed and activated.
Private, payment, email, and analytics integrations are disabled or configured for a safe test mode.
No local change is being mistaken for a deployment to the live site.

Make the local URL open reliably

Keep the local tool or Docker engine running before opening the URL.
Use the exact scheme, host, and port shown by the environment, including https when it provides TLS.
If a custom domain is configured, make sure its hosts-file or local DNS entry resolves to your computer.
Use a private browser window when testing cookies, redirects, or a fresh login.
Record the URL in your project README so teammates know which address is configured.

Common errors and fixes

Symptom	Likely cause	Fix
“This site can’t be reached”	The environment is stopped or the port is wrong	Start the tool, then copy the current URL it reports. Check for another process using that port.
Connection refused	Web server or Docker is not running	Start the required service and retry. Inspect the tool’s logs for startup errors.
Database connection error	Wrong database name, user, password, host, or port	Compare `wp-config.php` or installer values with the database service configuration.
Too many redirects	WordPress URLs still point to HTTPS or the production domain	Correct the local home and site URLs, then clear browser cookies and caches.
Missing images or CSS	Absolute production URLs remain in content or generated caches	Run the migration tool’s URL-replacement procedure and clear cache files.
Plugin or theme fatal error	Version or PHP incompatibility	Disable the failing extension from the dashboard, filesystem, or WP-CLI, then match the local versions to the project requirements.
Blank white page	A PHP fatal error or exhausted memory limit	Read the PHP and WordPress debug logs, enable development logging locally, and increase the local memory limit only after identifying the failing code.
`wp-env start` fails	Docker is stopped, dependencies are missing, or a port is occupied	Start Docker, reinstall project dependencies, and choose a free port according to the current wp-env documentation.
Changes disappear after restart	The environment is disposable or files were edited outside its mounted project	Use a persistent volume or mounted project directory and export data when the tool requires it.

Performance, reliability, and cost considerations

Performance: local requests avoid network latency, but a laptop can be slower than production when importing a large database, generating thumbnails, or running many plugins. Keep only required services running.
Reliability: local data is not a backup. Export the database and preserve uploads and source code before deleting or recreating an environment.
Repeatability: record tool versions, PHP and database versions, plugins, and the local URL or port. A project configuration file or Docker setup helps teammates reproduce the same environment.
Cost: the software choices listed here are development tools; your cost depends on the tool, hosting, storage, and computer you use. A local copy does not replace production hosting.
Security: do not expose a local development server publicly unless you understand its authentication, firewall, and data risks. Use non-production credentials and test payment and email integrations safely.

Or skip the browser setup

If you only need an image or PDF of a WordPress URL, ScreenshotNeo returns it from one request. See the ScreenshotNeo API documentation for the full option list.

cURL

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com -o shot.webp

Python

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

Node.js

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot failed: ${res.status}`);
const fs = await import('node:fs/promises');
await fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));

ScreenshotNeo can load lazy images, capture a full page or one CSS-selected element, set a viewport or device preset, use dark mode, wait for a selector, delay, or network idle, run custom CSS and JavaScript, click an element, hide selectors, set headers, cookies, user agent, authorization, timezone, and geolocation, block ads, trackers, requests, or resource types, resize images, cache with a chosen TTL, create PDFs, generate signed links, run asynchronous jobs with signed webhooks, and capture up to 100 URLs per bulk call.

Cookie and consent banners, newsletter popups, and chat widgets are removed before capture. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed; response headers identify the page verdict and whether the request was billed. An MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients.

The Free plan includes 1,000 screenshots each month with no card. Paid plans start at $5 for 3,000 shots; every feature is available on every plan. Create a free ScreenshotNeo account.

FAQ

Is `localhost` the same for every WordPress installation?

No. The host and port come from your local environment. localhost:8888 is only a documented wp-env example.

Can I view a local site without internet access?

Once the environment, WordPress files, database, and required dependencies are installed, the site itself can usually be opened locally without an internet connection. External fonts, APIs, updates, and remote media may still need network access.

Does local WordPress automatically update the live site?

No. Local and production are separate environments. Deploy only through an intentional, reviewed migration or version-control workflow.

Which method should a beginner choose?

Start with a managed desktop tool or Playground. Choose wp-env or Docker when your project needs a reproducible developer workflow, and use a manual stack when you need direct control of each service.

Can I screenshot a local-only URL with ScreenshotNeo?

ScreenshotNeo captures URLs it can reach from its service. A private localhost address is on your computer, so publish a securely reachable test URL or capture the page locally with a browser tool when the page must remain private.