Should You Delete Original Images After WordPress WebP Conversion?

After converting WordPress images to WebP, deleting originals can look like an easy storage win. Sometimes cleanup is appropriate. But deleting too early can make rollback difficult, break external uses, weaken future exports, or remove the only high-quality source the site has.

The better question is not "Can we delete originals?" It is "Which originals are still needed, and what evidence do we have?"

A careless answer treats original deletion as an automatic next step after conversion. That is dangerous. A useful recommendation has to separate source uploads from generated WebP/AVIF siblings, prove current references, preserve backup or archive paths, and name the reviewer who accepts the rollback and reuse risk.

For GetWebP, this distinction is especially important. The WordPress FAQ describes the plugin's sibling-file model: the original upload stays in place, while WebP and AVIF variants are stored beside it. Deleting generated variants is not the same decision as deleting the source upload.

Originals Are More Than Redundant Files#

An original upload can serve several roles:

• source for regenerated sizes
• fallback for browsers or external systems
• reference for visual comparison
• asset for social or email reuse
• source for future crops
• rollback target if WebP output fails
• archive of licensed creative work

A WebP derivative may be the right delivery file for the website, but it is not automatically a replacement for every future use.

GetWebP's batch conversion documentation is explicit that original images are not modified during conversion. It also documents the "Delete WebP" and "Delete All WebP Files" paths for generated variants. Those controls remove .webp and .avif siblings; they should not be described in an article as deleting the canonical WordPress originals.

Check How WordPress References Media#

WordPress stores media as attachments with metadata, captions, alt text, generated sizes, and relationships to posts or products. The WordPress Media Library documentation explains how editors interact with those assets.

Before deletion, identify whether the original file is connected to:

• a featured image
• post content
• gallery block
• product image
• theme option
• custom field
• page builder field
• Open Graph image

Do not assume that a file is unused because it does not appear in one post search.

Use an attachment-level audit before any source deletion:

Attachment ID: 18421
Original path: /wp-content/uploads/2025/11/product-angle-a.jpg
Generated siblings: product-angle-a.jpg.webp, product-angle-a.jpg.avif
Current references: WooCommerce gallery, /products/travel-bag/
External references checked: Google Merchant Center, email campaign, og:image
Regeneration need: keep original for future product zoom sizes
Decision: keep original; allow WebP/AVIF delivery
Reviewer: ecommerce owner

This is the level of evidence that separates useful cleanup from a risky storage sweep.

Consider Responsive Image Regeneration#

WordPress may need to regenerate image sizes after a theme change, layout redesign, or plugin update. The official responsive images guide explains how generated sizes support srcset output.

If the original is gone, regeneration may have to use a compressed derivative. That can lower quality or limit future size choices. Keeping originals gives the site more flexibility when templates change.

This matters most for hero images, product photos, photography portfolios, and screenshots used in documentation.

It also matters for rollbacks. GetWebP's frontend delivery documentation explains that optimized files are delivered through URL rewriting or picture markup. If delivery is disabled, URLs can fall back to the original JPEG/PNG path. That fallback is only useful if the original still exists.

Separate Storage Cleanup From Delivery Optimization#

WebP conversion improves delivery when the optimized file is served to users. Deleting originals improves storage usage. Those are different goals and should be reported separately.

For example:

Delivery optimization: WebP served on product pages
Storage cleanup: 2.4 GB archived from unused media
Source retention: originals kept for active product catalog

This prevents a risky deletion from being justified by a performance goal it does not directly affect.

Report the two numbers separately:

Page delivery result: WebP/AVIF variants served on 95 percent of public image requests
Source cleanup result: 0 active originals deleted
Generated-variant cleanup: 1.1 GB old WebP/AVIF siblings removed before re-optimization
Archive result: 2.4 GB inactive campaign originals moved to controlled storage

That wording avoids the misleading claim that deleting originals is part of serving faster images.

Archive Before Deleting#

If storage pressure is real, archiving originals outside the active WordPress uploads path may be safer than deleting them outright. An archive can live in object storage, a backup system, a design asset library, or another controlled location.

The archive should preserve:

• original filename
• upload date
• related attachment ID if available
• page or product reference
• license or credit notes
• checksum or verification record

An archive without a retrieval path is only slightly better than deletion.

Before moving originals out of WordPress uploads, test one restore:

Restore test: completed
File restored to original path: yes
Attachment metadata intact: yes
Generated sizes can be rebuilt: yes
Public page fallback works after cache purge: yes
Archive owner: operations

If the team cannot restore a sample file, it should not delete production originals yet.

Identify Safe Deletion Candidates#

Some files can be deletion candidates after review:

• duplicate uploads with no references
• old campaign images no longer linked anywhere
• failed upload remnants
• generated derivatives that can be recreated
• unused test images from staging
• temporary files from past plugins

Even then, use backups and staged cleanup. Do not mix obvious junk with important source originals in one deletion pass.

Check External Uses#

WordPress may not know where an image is used outside the site. Emails, ads, PDFs, partner pages, marketplaces, and old social posts may link directly to image URLs.

For active campaigns and ecommerce assets, review known external uses before deleting. If direct URLs must disappear, decide whether redirects, replacements, or communication are needed.

The more public an image URL has been, the more cautiously it should be removed.

Pay special attention to preview images. A site may serve WebP inside articles while keeping JPEG or PNG for og:image, newsletters, marketplace feeds, or partner documentation. That is a normal compatibility choice, not a failed WebP migration.

A Practical Decision Matrix#

Use a simple classification:

Keep: active product, hero, editorial, or reusable source
Archive: old but potentially reusable or licensed asset
Delete: duplicate, unused, backed up, and not externally referenced
Regenerate: derivative that can be recreated from retained source
Investigate: unclear attachment or external reference

This gives the team a way to move without treating every file the same.

Add one more rule for generated variants:

Delete generated variant: .webp/.avif sibling no longer wanted, original retained
Delete original: source upload no longer referenced, archived or backed up, and approved

Keeping those actions separate prevents a media-library cleanup task from silently becoming a source-asset deletion project.

Deleting originals after WordPress WebP conversion should be a storage decision backed by evidence, not an automatic optimization step. Keep or archive sources until the site, editors, backups, and external references no longer need them.