Full WordPress Disk: Auditing the EWWW Image Backup Folder
A bloated EWWW IO image backup folder appears when the disk fills. Learn the backup mechanism, official trimming paths, and safety criteria before deleting.
TL;DR
A production server hit 100 percent disk usage, and the EWWW Image Optimizer backup folder turned out to hold 14 gigabytes. The folder grows from pre-optimization originals, downscaled originals, and WebP copies, each with its own official cleanup command. Verify an independent, restorable backup first, map the folder composition, then run the matching command.
Server monitoring showed disk usage touching 100 percent. Clearing logs and temporary cache brought it down to 95 percent, still a dangerous number for a production server. A follow-up audit with du -sh wp-content/* found the largest contributor: the image backup folder belonging to the EWWW Image Optimizer plugin, at 14 gigabytes. The finding is still pending because the composition of that folder has not been mapped.
The first suspect is usually the optimization process itself, accused of duplicating files. The official documentation rejects that accusation. Regular optimization overwrites the original file with the compressed version; it does not add a copy. The EWWW_IMAGE_OPTIMIZER_DELETE_ORIGINALS constant only covers format-conversion leftovers such as PNG to JPG, with no effect on regular optimization [4].
What the wp-content/ewww folder contains, per the official docs
The EWWW IO local backup folder lives in wp-content/ewww/ by default. If that directory is not writable, the plugin moves backups to uploads/ewww/, and files optimized outside wp-content end up in ../ewww/root/ [1]. Knowing this location matters because disk audits keep finding the folder without any context about where it came from.
The plugin ships two backup modes. Local mode keeps copies of the original files on your own server, while Cloud mode stores them on the EWWW IO API servers for up to 30 days [2]. Local backups and lossless compression with 8 percent average savings are available for free, while the 30-day cloud backup belongs to the premium package [6].
The folder grows from three distinct sources. First, backup copies of the original files taken before optimization [1]. Second, the original uploads that WordPress downscales when width exceeds 2560 pixels; the original stays on disk [3]. Third, WebP copies created for browser compatibility, with conversion savings averaging 60 percent [6].
Official trimming options
For the second source, the plugin provides the WP-CLI command wp ewwwio remove_originals. It removes the originals that WordPress kept during downscaling and leaves only the full-size 2560-pixel version [3]. Running it through WP-CLI also avoids the PHP timeouts that plague web-based bulk processing.
WebP copies are handled by the WebP cleanup tool, which removes all local .webp files [3]. This option makes sense when modern-format delivery is already handled by another layer, for example a CDN converting on the fly, so the local copies are no longer needed.
Prevention lives in the Resize settings. The documentation says these settings save large amounts of disk space, and EWWW IO does not keep the original when downscaling a full-size image [5]. Meanwhile, DELETE_ORIGINALS stays in its lane: deleting originals only for images that changed format [4].
Safety criteria before deleting
The vendor warning is blunt: never rely on EWWW IO backups as the only line of protection [2]. Before a single file is removed from the backup folder, an independent site backup must already exist and be verified as restorable. Without that precondition, deleting the backup folder trades disk space for the ability to recover images at their original quality.
The working order: map the composition first with du per subfolder, then pick the command that matches the growth source. A folder dominated by WebP copies responds to the WebP cleanup tool; one dominated by downscaled 2560-pixel originals responds to remove_originals. Wiping the whole directory at once throws away both opportunities along with the restore capability.
After execution, rerun the disk audit. The folder size drop should approach the estimate of removed files. If overall disk usage stays high, extend the audit to the uploads directory and system logs before calling the problem solved.
On this server, the 14-gigabyte finding is still waiting for its composition map. That number will come down with one official command, but the command must wait until the independent backup is verified. Disk space can wait; lost images do not come back.