PHP in WebAssembly vs Server-Side PHP

Server-side PHP runs on a web server and sends the finished HTML over the network. PHP in WebAssembly (Wasm) runs the PHP interpreter inside your browser tab. Wasm PHP gives instant, private feedback once it has loaded, which makes it well suited to playgrounds and learning. Server-side PHP remains the right choice for production apps, databases and anything involving secrets.

Key takeaways

WebAssembly PHP is the regular PHP interpreter, written in C and compiled to a .wasm binary, running on your own device.
After the initial download, each run skips the network round trip. The first load, however, has to download the whole runtime.
Server-side PHP can reach databases, the file system and private credentials. Browser PHP runs in a sandbox and can't.
Any code or data shipped to the browser is visible to the user, so secrets must stay on the server.
WebFiddle's PHP sandbox uses the open-source php-wasm project and lets you choose PHP 8.0 to 8.5.

How server-side PHP works

When you visit a WordPress site or a Laravel app:

Request: your browser sends an HTTP request to the server.
Network: the request travels to the server's data centre.
Execute: the web server (for example, Nginx with PHP-FPM) hands the request to a PHP worker.
Data: PHP may query a database such as MySQL, which is often another network hop.
Render: PHP builds the HTML response.
Response: the HTML travels back and the browser displays it.

Every interaction repeats the round trip, so the delay depends on distance, network quality and server load, as well as how long your PHP code takes to run.

How PHP in WebAssembly works

WebAssembly is a portable binary format that browsers execute in a sandbox. Because PHP's interpreter is written in C, it can be compiled to WebAssembly with the Emscripten toolchain.

WebFiddle doesn't build its own PHP binary. The PHP sandbox loads php-wasm, an open-source project by Sean Morris (source on GitHub, published to npm as php-wasm), from a CDN. The process looks like this:

Download: the first time you open the sandbox, your browser fetches the php-wasm JavaScript loader and the WebAssembly binary. Later visits may be served from the browser cache.
Execute: when you click Run, the PHP interpreter runs your script on your device's CPU.
Display: the output is shown in the page without any request to a PHP server.

You can pick PHP 8.0, 8.1, 8.2, 8.3, 8.4 or 8.5 from the version selector (8.4 is the default), which makes it easy to check how code behaves across releases.

Latency, privacy and limits compared

We haven't published benchmarks, because results depend heavily on the device, browser, PHP build and network. The qualitative differences are consistent, though:

	Server-side PHP	PHP in WebAssembly
First run	Fast if the server is warm; nothing extra to download	Slower: the runtime must be downloaded and initialised
Later runs	Each run pays a network round trip	No network round trip; output appears as soon as the script finishes
Raw execution speed	Native code, can use OPcache and JIT	Usually slower than native PHP on the same hardware
Privacy	Code and input are sent to the server	Code runs locally in the tab
Databases	Direct connections to MySQL, PostgreSQL and others	No direct TCP connections; data must come through browser APIs
Secrets	Can stay on the server	Anything in the browser is visible to the user
Extensions	Whatever the server installs	Limited to what the Wasm build includes
Scale	You pay for server capacity	Each visitor's device does the work

Where WebAssembly PHP wins: the feedback loop

For learning and prototyping, the delay that matters is the time between editing code and seeing the result. With a traditional setup, you save the file, possibly upload it and refresh the browser. In a browser-based sandbox, you edit and click Run. Once the runtime is loaded, nothing else stands in the way.

Where server-side PHP wins: everything production needs

Database access: browsers can't open raw TCP connections to a database port such as MySQL's 3306. A browser app would still need an HTTP API to reach its data.
Initial payload: a WebAssembly PHP runtime is a much larger download than a typical server-rendered HTML page, which matters on slow mobile connections.
Secrets and business logic: you can't hide code that runs on the client. API keys, passwords and pricing rules must stay on the server.
Ecosystem: production frameworks such as Laravel and Symfony expect a full server environment with Composer packages, extensions, a writable file system and background workers.

When to use each

Use server-side PHP for:

Production applications built with Laravel, Symfony or WordPress.
Anything that talks to a database or handles authentication and private data.
Code that must keep secrets.

Use PHP in WebAssembly for:

Code playgrounds and interactive documentation.
Teaching and tutorials, where students shouldn't need to install PHP.
Quick checks of syntax or behaviour across PHP versions.
Offline-capable tools, such as formatters and converters, that don't need a server.

Want to see what changed between releases? Read our overview of PHP 8 features from 8.0 to 8.5, or learn more about WebAssembly's role on the web.

Frequently asked questions

Is PHP in WebAssembly faster than server-side PHP?

It depends on what you measure. Raw execution is usually slower than native PHP on the same machine, and the first load has to download the runtime. After that, each run skips the network round trip, so small scripts in a playground often show results sooner than sending them to a remote server would.

Can PHP running in the browser connect to a MySQL database?

Not directly. Browsers don't allow web pages to open raw TCP connections, so php-wasm can't reach MySQL on port 3306. Browser PHP can work with data provided through browser APIs, or with an in-browser database such as SQLite if the build includes it. Production data access still needs a server-side API.

Which PHP versions does the WebFiddle PHP sandbox support?

The WebFiddle PHP sandbox lets you choose PHP 8.0, 8.1, 8.2, 8.3, 8.4 or 8.5 from a version selector, with PHP 8.4 selected by default. All versions run through php-wasm in your browser, so you can switch versions and rerun the same script to compare behaviour and new features.

Is my PHP code private when it runs in WebAssembly?

The code you run in the WebFiddle PHP sandbox executes on your own device and isn't sent to a PHP server. It only leaves the browser if you create a share link or your script makes network requests. Never treat client-side code as secret, because anyone using the page can inspect it.

Did WebFiddle compile PHP to WebAssembly itself?

No. WebFiddle uses php-wasm, an open-source project maintained by Sean Morris that compiles the official PHP interpreter to WebAssembly with Emscripten and publishes it to npm. WebFiddle loads the published runtime from a CDN and adds the editor, version selector, output panel and sharing features around it.

Key takeaways#

How server-side PHP works#

How PHP in WebAssembly works#

Latency, privacy and limits compared#