Parse Error: Syntax Error After Editing functions.php (How to Fix)

← Back to all WordPress fixes

Introduction

You added a snippet of code to functions.php, saved the file, and now your entire site — front end and wp-admin alike — shows a wall of raw, ugly text like:

Parse error: syntax error, unexpected '}' in /home/yoursite/public_html/wp-content/themes/yourtheme/functions.php on line 42

This looks alarming, but it’s actually one of the easiest WordPress errors to diagnose — PHP is telling you the exact file and the exact line number where it broke. Here’s what it means and how to fix it.

What a Parse Error Actually Means

A parse error means PHP couldn’t even understand your code well enough to start running it — there’s a typo in the code’s structure itself, not in the logic. It happens before WordPress, your theme, or any plugin gets a chance to load anything. The most common causes, in order of likelihood:

• A missing semicolon at the end of a line
• Unmatched brackets or parentheses — one { without its closing }, or vice versa
• “Curly” quotes (“ ” ‘ ’) instead of straight quotes (" ') — this happens constantly when you copy code from Word, Google Docs, or a website that auto-formats quotes
• An extra closing ?> tag or a stray character pasted by accident
• A snippet that was cut off when copying — missing its final line or bracket

Fix 1: Read the Error — It Tells You Exactly Where

Unlike most WordPress errors, this one hands you the answer directly: the file path and line number are right there in the message. If you can see this message on screen, skip to Fix 2. If WP_DEBUG_DISPLAY is off and you just see a blank white page or a generic critical error instead, temporarily enable display errors by adding this to wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', true );

Reload the site once to see the exact parse error message, then continue below. Remember to turn this back off afterward.

Fix 2: Edit the File via FTP or File Manager

Because a parse error can lock you out of wp-admin too, you’ll need to edit the file directly on the server:

1. Connect via FTP (e.g. FileZilla) or your host’s File Manager.
2. Navigate to wp-content/themes/your-theme/functions.php (the path from the error message tells you exactly where).
3. Open the file and go to the line number mentioned in the error.
4. Look for the issue: a missing ;, an extra or missing { / }, or a curly quote where a straight one should be.
5. Fix it, save the file, and reload your site.

If the error persists after saving, double-check the line above the one mentioned too — a missing semicolon on line 41 often surfaces as an error on line 42.

Fix 3: When in Doubt, Remove the New Code Entirely

If you can’t spot the problem, the fastest path back online is to remove exactly what you added and get the site working again before troubleshooting further:

1. Delete the snippet you just added (the code between where it starts and where the file continues normally).
2. Save and reload — your site should be back.
3. Re-add the snippet slowly, checking it character by character, or paste it into a plain text editor (Notepad, not Word) first to strip any hidden formatting before pasting it into functions.php.

Fix 4: Restore From a Backup

If you have a backup from before the edit, restoring functions.php alone (or the whole site) is often faster than debugging line by line — especially under pressure. This is exactly the kind of five-second fix a backup taken before editing code is meant for.

How to Avoid This Next Time

• Never paste code from Word or Google Docs directly. Paste into a plain text editor first to strip smart quotes and hidden characters.
• Use a code snippets plugin (like Code Snippets) instead of editing functions.php directly — a broken snippet there gets safely disabled instead of crashing your whole site.
• Use a child theme so theme updates don’t wipe out your customizations and you’re not editing core theme files.
• Take a quick backup before editing any code file — it turns this whole scenario into a non-event.

Frequently Asked Questions

Is this the same as “There Has Been a Critical Error”?
Related, but not identical. WordPress’s fatal error protection (added in WordPress 5.2) usually catches PHP errors and shows that friendly message plus a Recovery Mode email. A raw “Parse error” text instead means either WP_DEBUG_DISPLAY is on, or the error occurred in a way that bypassed the fatal error handler. Either way, the fix is the same: find the file and line, fix the syntax.

Why didn’t I get a recovery email like other critical errors?
Recovery Mode emails require WordPress’s own error handling to run first. Severe parse errors in certain files can occur early enough that this handler never gets a chance to fire, so no email is sent. This is normal for this specific error type — go straight to editing the file via FTP.

I fixed the syntax but the site still shows an error — why?
There may be a second issue on a different line, or a cached version of the broken page is being served. Clear any caching plugin and your browser cache, then reload.

Can this happen from a plugin instead of a theme?
Yes — any PHP file with a syntax error causes the same symptom. If the error message references a path inside wp-content/plugins/ instead, the same steps apply there.

Conclusion

A parse error looks scary because it’s raw and technical, but it’s actually the most self-explanatory WordPress error there is — PHP tells you exactly which file and which line broke. Fix the syntax via FTP, and if you can’t spot it, simply remove what you added and start over more carefully. A backup taken before the edit makes the whole thing a non-issue.