PHP Parse Error: syntax error, unexpected token (How to Fix)

A parse error means PHP could not even read your file as valid code, so nothing in that file ran. The message names a line and an unexpected token, but the actual mistake is very often on the line above, because PHP only notices the problem when it reaches something that cannot follow what came before.

You see it right after editing a PHP file, uploading a plugin or theme, or upgrading PHP. With display_errors on you get the text in the browser. With it off, which is correct for production, you get a blank page or an HTTP 500, and the message appears only in the error log.

What the message looks like

PHP 8 reports tokens in a readable form; PHP 7 used older wording:

PHP Parse error:  syntax error, unexpected token "}", expecting end of file in /var/www/html/index.php on line 42    (PHP 8)
PHP Parse error:  syntax error, unexpected '}' in /var/www/html/index.php on line 42                                  (PHP 7)
PHP Parse error:  syntax error, unexpected end of file in /var/www/html/functions.php on line 118

Causes, most likely first

1. A missing semicolon, quote, bracket or parenthesis on or just before the reported line.
2. Unbalanced braces. An extra or missing { or } produces "unexpected end of file" far from the real mistake.
3. Code written for a newer PHP than the server runs. Features such as match, named arguments, the nullsafe operator ?->, union types, enum or readonly properties fail to parse on older versions, and the error often points at a perfectly normal-looking line.
4. A damaged upload or edit. A partially transferred file, a pasted snippet with smart quotes, or a stray character from a word processor.
5. Short open tags and heredoc issues. <? without php can be disabled, and a heredoc closing marker with wrong indentation breaks parsing on versions before 7.3.

Step 1: let PHP lint the file

The quickest way to get an exact location is the built-in syntax checker. It does not execute the file.

php -l wp-content/themes/mytheme/functions.php
# PHP Parse error: syntax error, unexpected token "}" in ... on line 42
# Errors parsing wp-content/themes/mytheme/functions.php

Check a whole project, printing only failures:

find . -name '*.php' -print0 | xargs -0 -n1 php -l 2>&1 | grep -v '^No syntax errors'

Run it with the same PHP version your web server uses. On servers with several versions, call the right binary explicitly, such as php8.2 -l file.php.

Step 2: read the line above

Open the reported line and look at the preceding one or two statements.

$total = $price * $qty      // missing semicolon here
echo $total;                // PHP reports the error on this line

Typical fixes:

• Add the missing ; at the end of the statement.
• Match every opening (, [ and { with a closer. Editors with bracket highlighting make this quick.
• Replace curly "smart" quotes with straight quotes ' and ".
• In arrays, check commas: ['a' => 1 'b' => 2] needs a comma between items.
• Make sure ?> closing tags are not followed by output in the middle of a statement.

Step 3: rule out a version mismatch

If the line looks correct, check the runtime version and compare it with what the code requires.

php -v

A pattern like unexpected token "=>" on a match expression, or unexpected '?' on ?->, means the server runs an older PHP. Either upgrade PHP in your hosting panel, or change the code to older syntax. Look in the plugin or framework's documentation for the minimum PHP version. Downgrading a site to old PHP is not a good fix, because unsupported versions no longer receive security updates; check php.net for current support status.

Step 4: restore a known-good file

When you cannot spot the problem, revert it:

git diff -- path/to/file.php        # see what changed
git checkout -- path/to/file.php    # restore the last committed version

Without version control, restore the file from a backup, or for a WordPress plugin or theme re-upload a fresh copy over FTP. For a WordPress site stuck on a blank page, rename the offending plugin folder to deactivate it; see WordPress white screen of death.

How to verify the fix

Run php -l on the edited file and expect No syntax errors detected. Then request the page and confirm it returns 200 with the HTTP Status Checker; a parse error on a normal production setup returns 500. Watch your PHP error log for new warnings while you click through the key pages. The Website Health Check catches other regressions you may have introduced, and an Uptime Monitor with a keyword check on your homepage alerts you if a later deploy brings the error back.

Next steps

• Confirm the status code with the HTTP Status Checker.
• Read Fix 500 Internal Server Error for other causes of a blank 500 page.
• If the failure is memory related rather than syntax related, see PHP Allowed memory size exhausted.
• Add a keyword check in the Uptime Monitor to catch broken deploys fast.

FAQ

Why does PHP report the wrong line?

PHP can only tell something is wrong when it reaches a token that cannot legally follow the previous one. The real mistake, such as a missing semicolon, is usually on the line before the one reported, or an unclosed brace much earlier in the file.

What is the difference between a parse error and a fatal error?

A parse error happens before any code runs, because the file is not valid PHP. A fatal error happens while code is running, such as calling an undefined function or running out of memory.

My site only broke after a PHP upgrade. What now?

Some code uses syntax or removed features that the new version rejects. Run php -l across the project with the new version, update the plugin or framework to a release that supports it, or roll PHP back temporarily while you fix the code.

Why do I see a blank page instead of the message?

Production servers normally set display_errors = Off so visitors never see file paths. The message is still written to the log named by error_log, or to your web server's error log.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.