Why WordPress debug.log grows so large
Every PHP warning, notice, and error your WordPress site generates gets appended to debug.log as a new line — including deprecation notices from plugins, database query warnings, and undefined variable errors that fire on every page load. A site with a few outdated plugins or a theme with loose code can generate thousands of lines per day. After a few weeks, the file can reach 50MB, 200MB, or more. At that size, a text editor either crashes or takes minutes to open it.
The real problem: you can't find the error that matters
A bloated debug.log is full of noise — repeated notices that have been firing for months, irrelevant warnings from plugins you rarely use. The critical error that caused this morning's white screen is buried somewhere in 300,000 lines. Without search or filtering, finding it means scrolling through a wall of text. Most developers either give up or delete the whole file, losing the context they needed.
How to check if your debug.log is growing out of control
Before anything else, check the file size. Connect to your server via FTP, open the wp-content/ directory, and look for debug.log. If you see a file over 10MB, it’s been accumulating errors for a while. Files over 50MB are common on sites that have had debug mode enabled for months without maintenance.
If you don’t have FTP access — or don’t want to use it — install **Quick Debug Log Viewer** from the WordPress plugin directory. It reads the file server-side and shows you the content from the dashboard. No FTP needed, no file size limit.
How to read a large debug.log without crashing your editor
Opening a 100MB text file in Notepad or TextEdit will either freeze the application or take several minutes. There are three practical options:
**Option 1 — Use a log viewer plugin** Quick Debug Log Viewer displays your debug.log paginated in the WordPress admin, with search and filter controls. It reads the file in chunks, so size doesn’t matter. Go to **Tools → Quick Debug Log Viewer** after activating.
**Option 2 — Read only the last N lines via command line** If you have SSH access: “` tail -n 500 wp-content/debug.log “` This shows only the last 500 lines — usually enough to see recent errors without loading the full file.
**Option 3 — Use a large-file editor** VS Code, Sublime Text, and similar editors handle multi-hundred-MB text files without crashing. If you already have these tools, open the file via FTP/SFTP mount.
How to search and filter for the error that matters
A raw debug.log is mostly noise — notices, deprecation warnings, repeated non-critical messages. The critical errors are a small fraction.
When using Quick Debug Log Viewer, the search bar at the top lets you filter by:
- **Keyword** — type a plugin slug, function name, or file path to show only lines containing that string
- **Error type** — filter to show only `Fatal`, `Warning`, or `Notice` entries
Start with Fatal errors. They are the ones that crash pages or cause white screens. Warnings and notices are lower priority and can be addressed later.
If you’re debugging a specific plugin, search for its folder name (e.g., `woocommerce`) to see only errors originating from that plugin’s files.
How to clear debug.log safely
Once you’ve read and noted the relevant errors, clearing the log makes sense — a smaller file is easier to monitor going forward.
In Quick Debug Log Viewer, the **Clear Log** button deletes the file content with one click. WordPress creates a new empty file the next time an error occurs.
**Before clearing:**
- Note any Fatal errors you haven’t investigated yet
- Check if there are recurring errors from a specific plugin — that plugin probably needs updating or replacing
- Consider downloading the log file first if you want a record
After clearing, refresh a few pages on your site and check the log again within a few minutes. The errors that reappear immediately are your active issues — the ones worth fixing now.
How to prevent debug.log from growing uncontrolled
The log grows because debug mode is on and errors are being generated. The fix is to:
1. **Fix the errors** — update outdated plugins, remove deprecated function calls from your theme, or replace plugins that generate constant warnings 2. **Disable debug mode when not actively debugging** — set `WP_DEBUG_LOG` to `false` in wp-config.php on production 3. **Use a log rotation approach** — clear the log weekly and only investigate it when a problem appears, rather than letting it accumulate indefinitely
Leaving `WP_DEBUG_LOG` enabled permanently on a production site is a habit that leads to exactly this problem: a log file so large it becomes useless.
- Why debug.log grows large and what that tells you
- How to view a large log file without crashing your editor
- How to search for specific errors or plugin names
- How to filter by error severity (Fatal, Warning, Notice)
- How to clear the log safely and start fresh
- How to avoid the file growing back uncontrolled
FAQ
Why is my WordPress debug.log so large?
debug.log grows because WP_DEBUG_LOG is enabled and your site is generating PHP errors, warnings, or notices on every page load. The most common causes are outdated plugins with deprecated functions, themes using removed WordPress APIs, or custom code with undefined variables. Each error adds a new line — on a busy site this can mean thousands of lines per day.
Can I just delete the debug.log file?
Yes, deleting debug.log is safe. WordPress will create a new empty file the next time a PHP error occurs. The risk is losing context: if you had a recent error causing a problem, deleting the log removes your only record of it. The better approach is to read and search the log first, note any critical errors, then clear it.
How do I open a WordPress debug.log that is too large for a text editor?
Standard text editors like Notepad or TextEdit struggle with files over 50MB. Your options are: use a log viewer plugin that reads the file server-side and paginates it (like Quick Debug Log Viewer), use a command-line tool like 'tail -n 200 debug.log' to read only the last 200 lines, or use a large-file editor like VS Code which handles big files without crashing.
Where is the WordPress debug.log file located?
By default, debug.log is in the wp-content/ directory of your WordPress installation, at wp-content/debug.log. You can change the location by defining a custom ABSPATH in wp-config.php, but most setups use the default path. If you don't see the file, WP_DEBUG_LOG may not be set to true in your wp-config.php.
How do I stop debug.log from growing back after clearing it?
Clearing the log only removes the history — the errors keep firing until you fix them. After clearing, watch which errors reappear first. Those are your active issues. Fix or update the plugin/theme causing them, then disable WP_DEBUG_LOG when you're done debugging by setting it to false in wp-config.php. Leaving debug mode on indefinitely on a production site is a security risk.
Is it safe to have WP_DEBUG enabled on a live site?
WP_DEBUG_LOG (writing errors to a file) is safe as long as WP_DEBUG_DISPLAY is set to false — which prevents errors from being shown to visitors. WP_DEBUG_LOG alone just writes to a file only you can access. Never set WP_DEBUG_DISPLAY to true on a live site, as it exposes PHP error details (including file paths and database info) to every visitor.