How to Pass Variables to the Next Page in PHP

An ordinary PHP variable exists only while its request is being handled. To use a value on another page, send it with the request or store it for later requests. A form sends named fields to the URL in action; PHP reads each submitted field from the matching request array on the next page.

The form field name is the key PHP uses to retrieve the value. GET puts it in the URL; POST sends it in the request body.

How PHP passes data between page requests

Each page load is a separate HTTP request. A variable such as $name created while handling the first request is not automatically available when PHP handles the next one. Choose a transport or persistence method according to how long the value is needed and whether it should travel through the browser.

Use GET or POST when the next page needs submitted form data. Use a session for server-side state that should be available across multiple requests. A cookie stores a small value in the browser and sends it back on later requests. These mechanisms move or retain data; they do not make untrusted input safe. Validate data for its intended use and escape it for the context where it is displayed.

Pass data with a GET or POST form

Set a form’s action to the receiving page and give each field a stable name. The method determines which request array receives those fields. This form submits a name to nextPage.php using POST:

<form action="nextPage.php" method="post">
  <label>Name <input name="name" type="text"></label>
  <button type="submit">Continue</button>
</form>

On nextPage.php, check that the expected key exists before using it. Escape the value when inserting it into HTML:

<?php
$name = $_POST['name'] ?? null;
if ($name !== null) {
    echo 'Hello, ' . htmlspecialchars($name, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
}
?>

This receiver is unexecuted in the supplied packet; when served as a web page, it prints a greeting only when the request includes name. The field name name must match the $_POST['name'] key. The null-coalescing operator lets the page handle a request where that field was not sent without reading an undefined array key.

For a GET request, use a link or form whose query field name matches the key read by nextPage.php. This link sends the name field with the value Alice:

<a href="nextPage.php?name=Alice">Continue as Alice</a>

Read that field from $_GET['name'] on nextPage.php, checking for it before displaying the value:

<?php
$name = $_GET['name'] ?? null;
if ($name !== null) {
    echo 'Hello, ' . htmlspecialchars($name, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
}
?>

This receiving-page example is unexecuted in the supplied packet because it depends on an incoming web request. The link’s query parameter name matches the receiver’s $_GET['name'] key. For a GET form, set its method to get and give each field a matching name. Encode dynamic values rather than concatenating arbitrary text into a URL. GET data appears in the address bar and can be kept in browser history, bookmarks, server logs, or referrer data. Use it for shareable, non-sensitive values such as a search term, not secrets.

POST places submitted fields in the request body, which avoids displaying them in the URL but does not encrypt them. Use HTTPS for transport protection and do not treat POST as a substitute for authorization or input validation. Avoid $_REQUEST when the source matters: it may combine GET, POST, and cookie data according to configuration, making it less clear which value the application is using.

Share data with a PHP session or cookie

A session keeps values on the server and associates them with a browser using a session identifier. Start the session before sending page output on every page that reads or writes session data. Use the same key on both requests. The first page stores the value:

<?php
session_start();
$_SESSION['animal'] = 'Dog';
?>

On the receiving page, start the session before output and check the same key before reading it:

<?php
session_start();
if (isset($_SESSION['animal'])) {
    echo htmlspecialchars($_SESSION['animal'], ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
}
?>

Sessions suit state such as a multi-page workflow or a signed-in user’s server-side data. Protect session identifiers with HTTPS and appropriate cookie settings, and still enforce access checks on every page.

To create a cookie, call setcookie() before output. The browser receives the cookie and can return it with a later request; PHP exposes that received value through $_COOKIE:

<?php
setcookie('animal', 'Dog', [
    'expires' => time() + 3600,
    'path' => '/',
    'secure' => true,
    'httponly' => true,
    'samesite' => 'Lax',
]);
?>

The new value normally appears in $_COOKIE on a subsequent request, not immediately in the current request. Do not assign to $_COOKIE to set a browser cookie; that only changes the current PHP array. Cookies are client-side storage and users can clear or alter them, so do not trust their contents for permissions or sensitive state. Store only what the browser needs and validate returned values.

On that later request, check and read the matching cookie key:

<?php
if (isset($_COOKIE['animal'])) {
    echo htmlspecialchars($_COOKIE['animal'], ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
}
?>

Choose a method and handle submitted values safely

Use GET for data that belongs in a shareable URL, POST for a form submission that changes or processes data, a session for server-side values needed across requests, and a cookie when a small browser-held value must be sent back later. Neither GET nor POST is inherently secure: HTTPS protects data in transit, while validation and authorization protect application behavior. Sessions keep the value server-side, but the session identifier still needs protection. Cookies are under the user’s control.

When troubleshooting, compare the form’s method and each input’s name with the receiver’s $_GET or $_POST key. Confirm that the form targets the expected action, and check for a missing key before reading it. For sessions, verify that both pages start the session before output and use the same key. For cookies, set them before output and inspect them on a later request. Escape values for their output context, such as with htmlspecialchars() for HTML, even after checking their format.