Originally published on zero2php.dev — part of the Zero to PHP course. View this lesson on the original site.
What “superglobal” means
In PHP, a superglobal is a built-in variable that is available in every scope—inside functions, methods, and file scope—without declaring global or passing parameters. That makes them convenient for HTTP, sessions, and environment data, but it also means any code path can read them, so discipline matters.
They are almost always arrays (or array-like access patterns) keyed by strings.
The usual superglobals
| Name | Role (one sentence) |
|---|---|
$_GET |
Query-string parameters from the URL (?key=value). |
$_POST |
Typical body fields for POST requests (often HTML forms). |
$_REQUEST |
A merged view of input (which sources are included depends on request_order / variables_order in php.ini). Prefer $_GET / $_POST explicitly when you can. |
$_SERVER |
Request and server metadata: method, host, URI, headers (often as HTTP_*), script name, and more—varies by SAPI and server. |
$_SESSION |
Per-visitor server-side storage once a session is active (you will call session_start() before use—covered in depth later). |
$_COOKIE |
Cookies the client sent with the request (name/value pairs you must treat as untrusted). |
$_FILES |
Uploaded files for multipart/form-data requests (tmp paths, sizes, errors). |
$_ENV |
Environment variables visible to PHP (depends on how PHP is run). |
$GLOBALS |
A registry of global variables by name; overlaps with user globals—use sparingly while learning. |
You do not need to memorize every key inside these arrays yet. The important skill is knowing which superglobal answers which question (“where did this string come from?”).
How they get populated
Under PHP’s web SAPI (Apache, nginx+PHP-FPM, Laravel’s php artisan serve, etc.), the runtime and web server cooperate to fill $_GET, $_POST, parts of $_SERVER, $_FILES, and $_COOKIE from the incoming HTTP request.
In the CLI (php script.php), many web-centric keys are empty or absent—for example there is no browser query string unless you build one for tests. That is normal and why examples sometimes use ?? or isset() when reading $_SERVER.
<?php
declare(strict_types=1);
// Example: safe read when a key may not exist (e.g. CLI vs web)
$method = $_SERVER['REQUEST_METHOD'] ?? 'CLI';
Sessions, cookies, and uploads (preview)
$_SESSIONis powerful for login state and shopping carts, but values live on the server tied to a session id—usually delivered via cookie. You will wiresession_start()and timeouts in later chapters.$_COOKIEholds what the client sent; it can be tampered with. Never trust it for security decisions without server-side verification.$_FILESis the right place to inspect uploads (never trust client-side filename alone).
Trust and validation
Treat every value you did not compute yourself as untrusted input: query params, form fields, cookies, headers reflected into $_SERVER, and uploaded file metadata. Validate (shape, length, allowed characters), then escape or parameterize for the next hop (HTML, SQL, shell—later lessons and other courses go deep here).
Repeating the habit early saves you from “it worked on my machine” bugs when data is hostile or merely surprising.
What comes next
The next lesson drills $_GET, $_POST, $_REQUEST, and $_SERVER with concrete patterns—this page is the map of the territory.
From Zero to PHP