What Is PHP?

PHP is a server-side scripting language: a program that runs on a web server, not in the visitor's browser. When someone requests a .php page, the server hands that file to the PHP interpreter, the interpreter executes whatever code is inside it, and the result of that execution — almost always plain HTML, sometimes JSON or a redirect header — is what actually travels over the network to the browser. The browser has no idea PHP was even involved. It just receives text and renders it like any other web response.

Server-side vs. client-side, concretely

"Server-side" and "client-side" describe where code executes, and that distinction has real consequences for what each piece of code can see and do. A client-side language like JavaScript runs inside the user's browser, on the user's machine, after the page has already been delivered. A server-side language like PHP runs on infrastructure you control, before the page is ever sent out. Compare these two snippets side by side.

greet.php — runs on the server

PHP

<?php

$hour = (int) date('H');
$greeting = $hour < 12 ? 'Good morning' : 'Good afternoon';

echo "<h1>{$greeting}, visitor!</h1>";

<h1>Good afternoon, visitor!</h1>

greet.js — runs in the browser

const hour = new Date().getHours();
const greeting = hour < 12 ? 'Good morning' : 'Good afternoon';

document.querySelector('h1').textContent = `${greeting}, visitor!`;

Look closely at what each snippet's "input" and "output" actually are. The PHP script's input is the server's clock and whatever request data it received (query strings, form fields, session data, database rows); its output is a finished string of HTML that gets written into the HTTP response body before the response ever leaves the server. The JavaScript's input is the visitor's device clock and the DOM already sitting in their browser; its output is a mutation of that already-loaded page, computed entirely on hardware you do not own or control. By the time greet.js runs, the page has already arrived — JavaScript is reshaping something the browser already has. By the time greet.php runs, the page does not exist yet — PHP is manufacturing it from scratch.

The browser never sees PHP source

This is the detail beginners most often get wrong: PHP code is not "hidden" from the browser through obfuscation or minification, it is never sent at all. The web server invokes the PHP interpreter, captures whatever the script produces, discards the source file, and transmits only the produced output. View-source on a PHP-powered page shows you HTML — never <?php ... ?> blocks, variable names, or database credentials — because those things were consumed entirely on the server before a single byte reached the client.

secret.php

PHP

<?php

$apiKey = 'sk_live_51Hxyz...'; // never leaves the server
$user = ['name' => 'Amara', 'plan' => 'pro'];

echo "<p>Welcome back, {$user['name']}! You are on the {$user['plan']} plan.</p>";

<p>Welcome back, Amara! You are on the pro plan.</p>

Whatever the browser receives when it requests secret.php is exactly that one <p> line — the $apiKey variable, the raw array, and the PHP syntax itself are gone. This is precisely why server-side languages are the right place to keep secrets, run database queries, and enforce business rules that a user should not be able to read or tamper with, while client-side JavaScript is the right place for things that must react instantly to user input without a network round trip: form validation feedback, animations, toggling a menu.

PHP's role in the LAMP / LEMP stack

PHP rarely runs alone. For decades, the default way to deploy it has been the LAMP stack — Linux, Apache, MySQL, PHP — or its close cousin the LEMP stack, which swaps Apache for Nginx ("LEMP" because Nginx is pronounced "engine-x"). Each letter is a layer with a distinct job:

Linux — the operating system the server runs on.
Apache or Nginx — the web server that accepts incoming HTTP requests, decides which files to serve, and, for .php files, hands the request off to the PHP interpreter (via a module like mod_php or, more commonly today, PHP-FPM over FastCGI).
MySQL (or MariaDB, PostgreSQL) — the database PHP talks to for anything that needs to persist between requests: user accounts, products, blog posts.
PHP — the layer that actually contains your application logic: it reads the request, queries the database, and assembles the HTML or JSON response.

A typical request flows through all four layers in order: the browser sends a request to Apache/Nginx, the web server routes .php requests to the PHP interpreter, PHP runs your script — which may query MySQL for data — and the finished output travels back through the web server to the browser. Understanding this pipeline matters because each layer has a different job and a different failure mode: a PHP script can be flawless and still fail to run if Apache is misconfigured, and a page can render perfectly and still be slow because of an unindexed MySQL query.

Request flow through a LAMP stack

Text

Browser
   │  GET /profile.php?id=42
   ▼
Apache / Nginx  ──(routes .php requests)──▶  PHP interpreter (PHP-FPM)
                                                     │
                                                     │  SELECT * FROM users WHERE id=42
                                                     ▼
                                                  MySQL
                                                     │
                                                     ▼  (rows)
                                              PHP builds HTML
                                                     │
   ◀──────────────── finished HTML response ────────┘
Browser renders the page

A common misconception: PHP files are not always run

A `.php` file only executes if the web server is configured to hand `.php` requests to a PHP interpreter. Serve the same file as a static asset — say, from a plain file server with no PHP module installed — and the "source code" is delivered verbatim to the browser as plain text, exposing everything you meant to keep hidden. This is why production servers are configured to run PHP for the relevant file extensions, and why you should never assume a `.php` file is "safe" just because it usually gets executed.

PHP can output more than HTML

Although the classic use case is generating HTML pages, a PHP script can just as easily `echo` JSON for an API endpoint, send a `Content-Type: image/png` header and stream binary image data, or emit a CSV file for download. "Server-side scripting language" means PHP runs on the server and produces *some* response body — the format is entirely up to what the script decides to output.

Tip

When you are unsure whether a piece of logic belongs on the server or the client, ask which side needs to trust the result. If the answer involves money, permissions, secrets, or anything a user could tamper with via browser dev tools, it belongs in PHP (or another server-side language) — client-side JavaScript is fine for anything purely cosmetic or advisory, but it should never be the last line of defense.