Superglobals ($_GET, $_POST, $_SERVER)
This is where PHP becomes a web language. Superglobals are the built-in arrays — $_GET , $_POST , $_SERVER and friends — that carry data from the browser into your script. You'll learn to read them, default them, and most importantly, treat them as untrusted.
Learn Superglobals ($_GET, $_POST, $_SERVER) in our free PHP course — a beginner-friendly interactive lesson with worked examples, a practice exercise and a…
Part of the free Php course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.
What You'll Learn in This Lesson
1️⃣ The Superglobal Family
PHP fills several built-in arrays for you on every request, each available in every scope. You'll use $_GET , $_POST , and $_SERVER constantly, with $_SESSION , $_COOKIE , and $_FILES arriving in later lessons. Because they're arrays, you always read them by key.
2️⃣ Reading $_GET (URL Data)
$_GET holds the URL's query-string parameters. Two things to internalise: keys may be missing (so always supply a default with ?? ), and every value arrives as a string (so cast when you need a number).
3️⃣ Reading $_POST (Form Data)
$_POST carries fields from a form submitted with method="post" . The discipline is the same — default missing keys, trim text — plus a non-negotiable step: validate before you trust anything. filter_var() is your friend here.
4️⃣ Inspecting the Request: $_SERVER
$_SERVER describes the request and environment — the HTTP method, host, requested URI, client IP, headers, and more. The most common use is branching on REQUEST_METHOD to decide whether to show a form or process a submission.
5️⃣ The Golden Rule: Never Trust Input ⚠️
Every value in a superglobal came from the client and can be forged . Two attacks dominate: XSS (echoing raw input lets an attacker inject scripts) and injection (putting raw input into SQL or shell commands). The defences: escape on output with htmlspecialchars() , validate or whitelist input, and use prepared statements for databases (covered later).
Now you try. Fill the ___ blanks to read query params safely.
🧩 Reorder Challenge
These scrambled lines should safely read and escape a name from the query string. Put them in the order that runs correctly (assume $_GET['name'] = 'Ada' ).
First read the value with a ?? default so a missing key can't error, then trim it, then escape it for safe HTML output, and only then echo. Escaping must happen before output — that's what stops XSS. Output: Hello, Ada .
🧠 Quick Recall
Predict the output before revealing each answer.
Prints string . All query and form values arrive as strings — cast with (int) when you need a number.
Prints none . The key is missing, so the null-coalescing operator falls back to the default instead of raising an "Undefined array key" warning.
Prints <b>hi</b> — the angle brackets are escaped, so the browser shows literal text instead of running it. This is the core XSS defence.
Common Errors (and the fix)
- "Warning: Undefined array key" — you read a key that wasn't sent. Default it with $_GET['k'] ?? 'fallback' .
- A number from $_POST behaves like text — it is a string. Validate then cast: (int) or filter_var .
- User input renders as live HTML/script — you echoed it raw (XSS). Wrap output in htmlspecialchars() .
- $_POST is empty after submit — the form is missing method="post" , or you're reading $_GET by mistake.
Pro Tips
- 💡 Default every superglobal read with ?? . Keys are optional; assume they can be absent.
- 💡 Validate on input, escape on output. Two habits that stop most web vulnerabilities cold.
- 💡 Prefer specific superglobals over $_REQUEST . Reading $_POST explicitly is clearer and safer.
📋 Quick Reference — Superglobals
Superglobal
Holds
Typical use
$_GET
URL query params
Search, filters, paging
$_POST
Form body
Sign-ups, comments
$_SERVER
Request/env info
Method, host, IP
$_COOKIE
Browser cookies
Preferences
$_SESSION
Server-side state
Login state
$_FILES
Uploads
Avatars, docs
$_REQUEST
GET+POST+COOKIE
Avoid — ambiguous
Frequently Asked Questions
Mini-Challenge: Contact Form Handler
Write it yourself, then check against the expected output in the comments. To run it live, serve the file and POST the form data described.
🎉 Lesson Complete!
- ✅ Superglobals are built-in arrays PHP fills on every request
- ✅ $_GET reads URL data; $_POST reads form data — both as strings
- ✅ Always default missing keys with ??
- ✅ $_SERVER describes the request; branch on REQUEST_METHOD
- ✅ Validate on input, escape with htmlspecialchars on output
- ✅ Next lesson: Null & Null-Safe Operators — ?? and ?->
Practice quiz
For the URL ?page=2, what does gettype($_GET['page']) return?
- 'integer'
- 'array'
- 'string'
- 'double'
Answer: 'string'. Every $_GET and $_POST value arrives as a string — cast with (int) when you need a number.
With no ?q in the URL, what does echo $_GET['q'] ?? 'none'; print?
- none
- An 'Undefined array key' warning
- null
- q
Answer: none. The key is missing, so ?? falls back to 'none' without raising an undefined-key warning.
Which superglobal holds data from a submitted <form method="post">?
- $_GET
- $_SERVER
- $_COOKIE
- $_POST
Answer: $_POST. $_POST carries form-body fields; $_GET carries the URL query string.
What does htmlspecialchars('<b>hi</b>') output?
- <b>hi</b>
- <b>hi</b>
- hi
- bold hi
Answer: <b>hi</b>. The angle brackets are escaped so the browser shows literal text instead of running it — the core XSS defence.
Which superglobal would you read REQUEST_METHOD from?
- $_SERVER
- $_GET
- $_POST
- $_SESSION
Answer: $_SERVER. $_SERVER describes the request and environment, including REQUEST_METHOD, HTTP_HOST, and REMOTE_ADDR.
Why should you avoid $_REQUEST?
- It is slower than $_GET
- It does not exist in PHP 8
- It ambiguously merges GET, POST, and COOKIE
- It only holds strings
Answer: It ambiguously merges GET, POST, and COOKIE. $_REQUEST merges $_GET, $_POST, and $_COOKIE; you can't tell the source, and a cookie could override a form field.
What is the safest way to handle a 'sort' parameter from the user?
- Echo it directly into the SQL query
- Whitelist it against an allowed list with in_array
- Trust it because it came over HTTPS
- Cast it to int
Answer: Whitelist it against an allowed list with in_array. Validate or whitelist input: check it against ['name','date','price'] and fall back to a safe default.
How should you treat all superglobal data?
- As safe because PHP fills it
- As already escaped
- As always numeric
- As untrusted user input that can be forged
Answer: As untrusted user input that can be forged. Everything in $_GET, $_POST, $_COOKIE and most of $_SERVER comes from the client and can be forged.
After $page = (int) ($_GET['page'] ?? 1); what is gettype($page)?
- 'string'
- 'integer'
- 'double'
- 'array'
Answer: 'integer'. The (int) cast converts the defaulted value to an integer.
Which pair of habits stops most web vulnerabilities?
- Echo raw, trust everything
- Use $_REQUEST everywhere
- Validate on input, escape on output
- Skip defaults to fail fast
Answer: Validate on input, escape on output. Validate or whitelist input and escape output with htmlspecialchars — two habits that block injection and XSS.
Continue this course
- Previous: Constants
- Next: Null & Null-Safe Operators (??, ?->)