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)

Pro Tips

📋 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!

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>
  • &lt;b&gt;hi&lt;/b&gt;
  • hi
  • bold hi

Answer: &lt;b&gt;hi&lt;/b&gt;. 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

Related lessons