Shrink images without ever touching the original
Set up an image optimizer WordPress media libraries can trust: scale, convert to WebP or AVIF, and see the real file size before committing — the original file is never overwritten, and Restore brings it back at any time.
- Original file is never modified — a new optimized copy is created instead.
- Byte-accurate size estimate before you convert anything.
- Always compresses from the highest-quality source available.
- Updates references everywhere — blocks, classic content, page builders.
Image optimizer WordPress: what does the module actually do?
This is what an image optimizer WordPress media libraries get with TheOneWP: an "Optimize" action on every image in the Media Library opens a modal to scale by percentage and convert to JPEG, PNG, WebP or AVIF. TOWP_Image_Optimizer compresses from the highest-quality source available — bypassing WordPress's own scaled-down upload copy when a true original exists — creates a new _opt file rather than overwriting anything, regenerates every WordPress thumbnail size from that same high-quality source, and rewrites references across Gutenberg blocks, classic content, and page-builder-safe database fields. A live, byte-accurate estimate shows the real output size before you commit, and Restore brings the untouched original back at any time.
Media libraries fill up with images nobody resized
A camera or phone photo dropped straight into WordPress is often several megabytes larger than the page actually needs, multiplied across every thumbnail size WordPress generates from it.
A destructive optimizer is a real risk
A tool that overwrites the original file the moment you convert it leaves no way back if the compressed result turns out worse than expected.
Format conversion can silently break other tools
Page builders and themes that store a direct reference to an image's URL can end up pointing at a file that no longer exists once a conversion changes its name.
Compress with a way back, and nothing left broken
The module treats the original as sacred, estimates honestly, and updates every reference that needs to know about the change.
The original is never touched
A new file is created for the optimized version; the source stays exactly as uploaded.
A real estimate, not a guess
The reported size comes from an actual compression pass at the requested settings.
References updated everywhere
Blocks, classic content, and page-builder-safe database fields all get the new URL automatically.
The complete image optimizer WordPress feature set
Every capability below is present in the class's optimize, estimate, or restore logic.
Original file, never overwritten
A new _opt file is created and referenced everywhere; the original stays on disk and restorable.
JPEG, PNG, WebP and AVIF
WebP and AVIF only appear when the server's GD library genuinely supports them — checked, not assumed.
Byte-accurate live estimate
An actual dry-run compression reports the real output size, with a specific correction for a documented same-format, quality-100 sizing bug.
Highest-quality source, every time
Compression and thumbnail regeneration both use the true pre-scaling original when WordPress created a scaled-down upload copy.
Site-wide, page-builder-aware URL updates
Covers Gutenberg blocks, classic content, srcset, and database rows — while deliberately skipping post-meta rewrites for the main URL to protect Bricks/Elementor-style stored references.
One-click Restore
Brings back the untouched original file and its original metadata at any time after optimizing.
Optimize an image optimizer WordPress upload in four steps
Check the estimate before committing, and know Restore is always available after.
Click "Optimize" in the Media Library
Available as a row action on any image, and inside the attachment edit screen.
Set scale, quality and format
Watch the live estimate update as you adjust each setting.
Convert and check the result
The new file replaces the reference everywhere the image appears on the site.
Restore if the result isn't right
One click brings back the exact original file and its metadata.
Where safe compression actually matters
The module fits sites where image weight affects load time but mistakes need to be reversible.
Photography-heavy sites
Large camera uploads get scaled and converted to WebP without losing the original file as a fallback.
Sites chasing Core Web Vitals
Smaller, modern-format images reduce page weight directly, with an estimate to confirm the trade-off before converting.
Existing media libraries with years of uploads
Go back through older, oversized images without any risk of losing the source file for good.
Compression that respects what was there before
Every design choice in the verified code favors reversibility and quality over an aggressive default.
Smaller images, correctly cached
The verified implementation makes sure a converted image is actually seen as new by browsers and caches.
Version-bumped URLs after every change
Optimizing or restoring bumps a version marker so cached copies of the old file don't linger in browsers or CDNs.
Assets load only where the modal is used
The optimizer's own CSS and JS enqueue only on the Media Library and post editor screens.
Memory limit raised only when needed
wp_raise_memory_limit( 'image' ) is called specifically around the compression work, not globally for the whole request.
Administrator-only, every single action
Every AJAX endpoint that touches a file or the database requires the same strict capability.
manage_options on every AJAX action
Info, estimate, optimize and restore all require this capability, alongside a verified nonce.
MIME type validated before processing
Only JPEG, PNG, GIF, WebP and AVIF sources are accepted — anything else is rejected before any file operation runs.
Sanitized filenames throughout
File names read from metadata pass through sanitize_file_name() before being used to build a file path.
Format support checked server-side, not trusted from the request
A requested format is validated against what the server's GD library can actually produce before any conversion starts.
Aware of how WordPress actually stores images
The supplied code accounts for WordPress's own upload-time scaling and how popular page builders store image references. No compatibility claim beyond the verified implementation is assumed.
WordPress's own upload scaling
Detects the original_image metadata WordPress records when it scales a large upload down, and uses that true original as the compression source.
Bricks & Elementor-style storage
Handles both plain and JSON-escaped URL formats in the database, matching how these builders serialize layout data.
render_block_core/image
Used specifically because WordPress 6.x's own block image renderer doesn't call the function core normally uses for size URLs — a targeted fix for a real gap.
TheOneWP versus common alternatives
Compare a real image optimizer WordPress implementation with typical dedicated image-compression plugins.
| Capability | TheOneWP Image Optimizer | Other common solutions |
|---|---|---|
| Original file safety | Never overwritten; a separate optimized file is created | Some plugins overwrite the original directly |
| Size estimate | Real compression pass, byte-accurate | Often a rough percentage estimate |
| Compression source | True highest-quality original, even past WP's own scaling | May compress from whatever file WordPress already scaled down |
| Page builder safety | Deliberate exception protects Bricks/Elementor references | Varies; some tools can break stored builder references |
| Restore | Full original file and metadata, one click | Not always available once a conversion is applied |
| Administration | Built into the Media Library, no separate screen | May require a dedicated bulk-optimization dashboard |
Compress with confidence, not guesswork
A few habits get the most out of a non-destructive optimizer.
Check the estimate before converting
Confirm the trade-off between size and quality actually makes sense for that specific image.
Prefer WebP or AVIF when the server supports them
Both typically produce a smaller file than JPEG at comparable visual quality.
Use Restore freely while testing settings
Since the original is always kept, there is no real cost to trying a setting and reverting if it doesn't look right.
Re-check pages built with a page builder after converting
The safeguards are real, but a visual check after a big batch of conversions costs little.
Avoid assumptions the code does not support
The module has a defined, verified scope — a few assumptions outside it cause confusion.
Expecting an animated GIF to stay animated
Optimizing a GIF flattens it to a static image — the warning shown before converting one exists specifically because this cannot be undone by re-optimizing.
Assuming WebP or AVIF is always available
Both depend on the server's GD build; if the check fails, that format simply won't appear as an option.
Deleting the attachment and expecting the backup to remain
Removing the image itself also removes its backup folder — Restore only works before the attachment is deleted.
Image Optimizer FAQ
These answers come directly from the verified class and its optimize/estimate/restore logic.
Does optimizing an image delete or overwrite the original file?
No. The module creates a new {name}_opt.{extension} file and updates every reference to point at it — the original file is never modified, and stays available for the Restore action at any time.
What does it actually compress from — the file I uploaded, or a WordPress thumbnail?
The highest-quality version available. If WordPress scaled your upload down on the way in, the module detects the true pre-scaling original and compresses from that, then regenerates every WordPress-generated thumbnail size from that same high-quality source too, instead of re-compressing an already-lossy copy.
Can I see the file size before committing to a conversion?
Yes. A live estimate runs the actual target scale, quality and format through a real compression pass and reports the genuine byte count — not a mathematical guess.
Why does the estimate behave differently at 100% quality and the same format?
Because re-encoding an already-compressed JPEG at GD's quality 100 uses different quantization tables than a camera's own JPEG encoder and can produce a dramatically larger file for no visual gain. In that specific case the module estimates by scaling the real original file size by area instead of re-encoding.
Does converting to WebP or AVIF break pages built with Elementor or Bricks?
The module specifically excludes the main image URL from post-meta rewriting when updating the database, because page builders like these store the original URL as a direct reference — only the file itself and its content-embedded references get updated, protecting builder-specific meta from corruption.
What happens to an animated GIF?
It gets flattened to a static image during optimization, and the module shows a clear warning about this before you convert one, since the animation cannot be preserved.
Are WebP and AVIF always available as conversion targets?
Only if the server's GD library actually supports them — checked with function_exists() for imagewebp() and imageavif() specifically. If the server can't produce one of those formats, it simply doesn't appear as an option.
What happens to the backup if I delete the image entirely?
It gets cleaned up automatically. The delete_attachment hook removes the corresponding backup folder so a deleted image does not leave an orphaned original behind.
Stop choosing between smaller and safe.Get both, with a real way back.
Use an image optimizer WordPress media libraries can trust: byte-accurate estimates, the highest-quality source every time, and an original that's never actually gone.