PHP Syntax Checker

How it works

What it does

The PHP Syntax Checker inspects pasted PHP source for parse and syntax problems. It focuses on structural validity: mismatched braces, unexpected tokens, unclosed strings, invalid attributes, and other issues that prevent the engine from compiling a script. Results are diagnostic text—not a runtime stack trace from executing your application.

Unlike running php -l on your laptop against a full project tree, this tool is built for a single snippet or file fragment you can paste quickly while reading a guide or reviewing a pull request.

When to use it

• You see Parse error or syntax error, unexpected... and want a second look at the exact fragment
• You are migrating older code and suspect a short open tag, heredoc, or attribute syntax mistake
• You want a fast check before pasting an example into documentation or a ticket
• A CI lint failed and you need to isolate one file’s problem without deploying

How input is processed safely

Submitted text is analyzed with a restricted, non-executing pipeline. The server does not call eval(), does not include your paste as a PHP file, and does not run shell commands. Size limits and rate limits apply so oversized pastes are rejected rather than processed unbounded.

Because execution never happens, runtime fatals such as undefined functions, type errors, or missing classes will not appear here—even if the code would fail when run. Use the error encyclopedia and your local runtime for those.

Examples

• Missing semicolon after a statement near the end of a file
• Unclosed single-quoted string that swallows the rest of the file
• Invalid named argument or attribute placement on older PHP versions you target
• Mismatched { } after an incomplete if/foreach refactor

Common mistakes

• Expecting the tool to prove business logic correctness—syntax validity ≠ correct behavior
• Pasting only half a class and misreading “unexpected end” as a different bug
• Assuming the checker’s PHP version matches your production SAPI without verifying
• Leaving short open tags (<?) that parse differently depending on short_open_tag

Syntax feedback is most useful when you paste a complete compilation unit: a full file, a complete function, or a closed class. Partial pastes can produce cascading “unexpected” messages that look worse than the real first error. If the report points near a string or heredoc, inspect quoting before chasing brace balance farther down the file.

For project-wide linting, keep using CI with php -l or static analyzers. This page is optimized for the interactive “one broken snippet” workflow that happens while reading error guides on ZendStudio.net.

Privacy note

Do not paste production secrets, private keys, customer data, or full application source. Prefer the smallest snippet that demonstrates the problem. Pastes are processed for analysis and are not meant to be a permanent code hosting service.

Safety notes

• Submitted tool contents are not written to analytics or search logs.
• This site never evaluates arbitrary PHP from the browser.
• Generated configs are starting points—validate on a staging host before production.