PHP File Documentation

Summary

A PHP Source Code File is server-side program text in PHP, the language that powers WordPress and much of the web. Its extension is .php and its MIME type is application/x-httpd-php. Open it in a text editor to read the code, but a browser will not run it: PHP executes on a web server, which runs the code and returns HTML. To see its output locally, run it under a server such as XAMPP or php -S.

Technical details

FeatureValue
Full namePHP: Hypertext Preprocessor source file
File extension.php
MIME typeapplication/x-httpd-php
Format typePlain-text server-side script (PHP mixed with HTML)
DeveloperThe PHP Group (originally Rasmus Lerdorf)
Introduced1995 (PHP/FI); PHP 8.x is current
ExecutesServer-side (Apache/Nginx with PHP-FPM or the PHP CLI)
Open/close tags<?php … ?>; short echo tag <?=
TypedDynamically typed; optional type declarations since PHP 7
Human-readableYes — editable in any text editor
SignatureNone (plain text); files usually open with <?php at offset 0
Comments// and # line, /* */ block
Includesinclude, require (and _once variants)
RunsWordPress, Drupal, Joomla, Laravel, Magento
Open standardYes — open-source interpreter
End-of-life riskPHP 5 and 7 are EOL; run a supported 8.x branch
Related extensions.phtml, .php5, .phps, .inc, .html
Specificationphp.net/manual/en/
Syntax at a glance

A .php file is plain text with no binary signature; it almost always opens with <?php at offset 0. Code lives between <?php and ?> tags, and anything outside those tags is emitted verbatim as literal HTML — PHP began as a templating layer over HTML. Statements end with a semicolon, variables start with $ ($name), and output is produced with echo. Other files are pulled in with include or require. The closing ?> is optional and is usually omitted in pure-PHP files to avoid stray whitespace in the response.

What is a PHP file?

PHP is a recursive acronym for PHP: Hypertext Preprocessor (originally “Personal Home Page”). A .php file is plain-text source code in the PHP scripting language, created by Rasmus Lerdorf in 1995 and now maintained by The PHP Group. It is one of the most common file types on the web: PHP runs the majority of content-management systems, WordPress, Drupal and Joomla among them, along with frameworks like Laravel and platforms like Magento. A typical file mixes PHP logic inside <?php ... ?> tags with literal HTML markup.

The defining fact about a .php file is where it runs. Unlike an .html file, which the browser renders directly, PHP executes on the server. When a browser requests a PHP page, the web server (Apache or Nginx with a PHP interpreter such as PHP-FPM) runs the code, queries databases, builds the page, and sends back plain HTML. The visitor never sees the PHP source. This is why double-clicking a .php from your hard drive does nothing useful: with no PHP engine to run it, the browser shows inert text or offers to download it.

PHP tags: how code and HTML interleave

PHP started as a way to embed small pieces of logic inside HTML pages, and that model still shapes the file. Any text outside the PHP tags is copied to the output untouched; anything between <?php and ?> is executed. A single file can switch back and forth many times.

<!DOCTYPE html>
<html>
<body>
  <h1><?php echo "Hello, " . htmlspecialchars($name); ?></h1>
  <?php if ($loggedIn): ?>
    <p>Welcome back.</p>
  <?php else: ?>
    <p><a href="/login">Please sign in</a></p>
  <?php endif; ?>
</body>
</html>

The parser reads the file top to bottom. Literal HTML is streamed straight to the response; each <?php ... ?> block is evaluated and its echo output is spliced in at that position. There is also a short echo tag, <?= $x ?>, equivalent to <?php echo $x; ?>. Because the closing ?> would otherwise emit any following whitespace into the response, files that contain only PHP conventionally omit the final ?> entirely.

The request lifecycle: from .php to HTML

Understanding a PHP file means following one HTTP request. The browser asks the web server for page.php. The server is configured to hand .php requests to a PHP interpreter (today usually PHP-FPM over FastCGI, historically mod_php inside Apache). The interpreter compiles the script to an internal bytecode (an opcode array), executes it, and returns the generated HTML to the server, which sends it to the browser. Each request starts with a fresh script state; PHP’s “shared-nothing” model means variables do not persist between requests unless stored in a session, a database, or a cache.

The same interpreter also runs from the command line. php script.php executes a file directly, and php -S localhost:8000 starts PHP’s small built-in web server so you can open http://localhost:8000/page.php and have the code actually run. This is the simplest way to see what a .php file produces without installing a full stack.

include and require: how PHP files assemble a site

Real applications are many .php files that pull each other in. Four constructs do this: include and require both insert and run another file at that point; the difference is failure handling. A missing include emits a warning and the script limps on; a missing require is a fatal error that halts execution, which is what you want for a critical file like a database config. The _once variants (include_once, require_once) refuse to include the same file twice, preventing duplicate function or class definitions. In a WordPress theme this is why editing functions.php, header.php or index.php changes the whole site: those files are required into every page render. Modern projects lean on Composer’s autoloader instead of hand-written includes, but the underlying mechanism is the same.

PHP versions and why old code breaks

PHP has moved fast. PHP 5 is end-of-life; PHP 7 (2015) brought large speed gains and a scalar type system; PHP 8 (from 2020) added the JIT compiler, named arguments, union types, enums and attributes. The consequence for a .php file is version sensitivity: code written for PHP 5 may not run unchanged on PHP 8. Functions removed across versions (the old mysql_* family, create_function(), each() ) cause fatal errors, and stricter type handling changes behaviour. A site that shows a blank page or errors right after a hosting provider bumps the PHP version is almost always hitting this. Running an out-of-support branch is also a security problem, because it no longer receives fixes.

Security: web shells, remote code execution and exposed secrets

Because a .php file is a program that the server runs, its security profile is unlike a passive document. Merely opening a .php in a text editor is safe; the danger is deploying or executing untrusted PHP on a live server. Three concrete attack mechanics matter.

Web shells. A single malicious .php uploaded to a site (classics are named c99 or r57) hands an attacker a remote command console. At its crudest it is one line: <?php system($_GET['cmd']); ?>. Once that file sits in a web-accessible folder, a request like shell.php?cmd=ls runs whatever the visitor supplies with the web server’s privileges, letting them read the database, plant malware, or pivot into the host. This is the payload behind most “my WordPress got hacked” incidents, usually dropped through a vulnerable plugin’s file-upload feature.

Remote code execution through includes. If a script builds an include path from user input, for example include $_GET['page'] . ".php";, an attacker can supply a path that pulls in a file they control (or, with certain PHP wrappers, raw code), executing it inside the application. This is why user input must never be used directly in include/require, in eval(), or in shell calls like system() and exec().

Exposed credentials. A .php config file typically contains a database password and API keys. Normally the server executes it and the secrets never reach the browser, but if the PHP handler is misconfigured or disabled, the server returns the source instead, leaking everything in plain text. Keep config outside the web root, keep PHP on a supported 8.x branch, and review any third-party .php before running it. (The .phps variant deliberately serves highlighted source and must never point at files holding secrets.)

Turning PHP into HTML output

“Convert PHP to HTML” is a common request but a slight misunderstanding: you cannot statically convert the source, because the whole point of the file is that its output depends on logic, database data and the request. What you can do is run the .php and capture the HTML it produces — open the executed page in a browser and use Save As, run curl/wget against the live URL, or for a CLI script redirect php file.php > out.html. Each of these captures one rendered snapshot and loses every dynamic behaviour. Similarly, “PHP to PDF” almost never means the source; it means generating a PDF from a page’s output using a library such as Dompdf, mPDF or TCPDF invoked from within the PHP code.

Frequently asked questions

How do I open a .php file?

To read or edit the code, open it in a text editor such as VS Code or Notepad++ — it is plain text. To see what it produces, run it on a server with PHP: locally via XAMPP or MAMP, or with php -S localhost:8000, then open the http://localhost URL. PHP executes server-side, not in the browser.

Why does my .php show as raw code in the browser?

Because no PHP engine ran it. Opening a .php from your hard drive does not execute it. Put it on a server with PHP (or a local stack) and reach it through an http://localhost address so the interpreter runs and returns HTML.

What opens functions.php in WordPress?

It is an ordinary PHP theme file — edit it in VS Code or Notepad++. It is required into every page render, so a single syntax error there can white-screen the whole site. Edit a copy and keep a backup.

References