by YoOhw Studio 0 (0 reviews)

Media Optimizer

Name: Media Optimizer
Author: YoOhw Studio

Free WebP and AVIF sidecars, delivery tests, and safe local WordPress image optimization with original-file backups.

Media Optimizer ranks #55,042 among WordPress.org plugins with 0+ active installations, is #3,855 of 5,058 in the Security category, and was last updated Oct 28, 2026. Data from WordPress.org, refreshed twice daily — see methodology.

Compatible with WP 7.1.4

v1.1.0 Current Version v1.1.0

Updated 1 week ago Last Update on 28 Oct, 2026

Refreshed 1 week ago Last Refreshed on

#3,855 of 5,058 in Security Downloads -81.3% this week Actively maintained

View on WordPress.org

Rank

#55,042

— No change

Active Installs

-100%

KW Avg Position

N/A

— No change

Downloads

379

+2 today

Support Resolved

— No change

Rating

Review 0 out of 5

0 (0 reviews)

Next Milestone 10

Total Progress 30%

0+ 10+

27,474

Ranks to Climb

Growth Needed

8,000,000

Active Installs

Pro

Unlock Exact Install Count

See the precise estimated active installs for this plugin, calculated from real-time ranking data.

Exact install estimates within tiers
Track install growth over time
Milestone progress predictions

Upgrade to Pro

Need 7 more installs to reach 10+

Rank Changes

Current #55,042

Change

Best #

Upgrade to Pro

Unlock 30-day and 90-day rank history charts with a Pro subscription.

Upgrade Now

Active Installs Growth

Upgrade to Pro

Active Installs 0,000,000+

Growth +0.0%

Peak 0,000,000

Downloads Growth

Downloads

Growth

Peak

Upgrade to Pro

Unlock 30-day, 90-day, and yearly download history charts with a Pro subscription.

Upgrade Now

Reviews & Ratings

0.0

0 reviews

Overall 0%

0 (0%)

Track This Plugin

Get detailed analytics, keyword tracking, and position alerts delivered to your inbox.

Start Tracking Free

Plugin Details

Version: 1.1.0
Last Updated: Oct 28, 2026
Requires WP: 6.4+
Tested Up To: 7.1.4
PHP Version: 7.4 or higher
Author: YoOhw Studio

Support & Rating

Rating: ☆ ☆ ☆ ☆ ☆ 0
Reviews: 0
Support Threads: 0
Resolved: 0%

Keywords

AVIF image optimization media library performance webp

Upgrade to Pro

Unlock keyword rankings, search positions, and detailed analytics with a Pro subscription.

Upgrade Now

Similar Plugins

Adminify – White Label, Admin Menu Editor, Login Customizer

6K+ installs

#2,757

Master Addons for Elementor – Elementor Addons, Widgets, Mega Menu Builder, Popup Builder, Widget Builder & Template Kits

Akismet Anti-spam: Spam Protection

5M+ installs

Wordfence Security – Firewall, Malware Scan, and Login Security

5M+ installs

#11

Really Simple Security – Simple and Performant Security (formerly Really Simple SSL)

Limit Login Attempts Security - Login Security, 2FA, Firewall, Brute Force Prevention

View all Security-and-spam-protection plugins

Frequently Asked Questions

Common questions about Media Optimizer

Not by default. It generates WebP or AVIF sidecars while leaving JPEG and PNG originals unchanged.

Yes, as an opt-in feature. A backup is required before an original physical file is replaced.

Without resizing, lossless JPEG optimization uses optional jpegoptim or jpegtran. If no smaller lossless output is available, the original is kept unchanged, including its metadata. Force retries do not enable lossy JPEG fallback. Resizing remains allowed in this mode and may re-encode the image, with a backup retained before replacement.

Oriented JPEG sidecars are normalized by a capable WordPress image editor before encoding, and original resize limits apply to displayed dimensions. Safe JPEG encoding requires an available PHP EXIF reader and successful orientation normalization. If either is unavailable, the source and existing sidecars are retained with an explanatory failure; PNG processing remains available. A lossless JPEG with nontrivial orientation is left unchanged when metadata removal is requested without resizing, including force runs. This keeps its appearance intact rather than stripping the orientation tag without a lossless display transform. Previously generated files are not automatically migrated or repaired; regenerate sidecars explicitly when needed. Backups and restore preserve the original bytes, including EXIF and ICC metadata. Other metadata preservation in re-encoded output remains engine-dependent; supported color profiles are retained separately from private metadata.

Supported RGB JPEG and PNG images retain their source ICC profile and color encoding, including supported sRGB, Display P3 and Adobe RGB compatible profiles. The plugin does not automatically convert wide-gamut images to sRGB. Removing private metadata keeps the color profile needed to interpret the pixels. Profile-aware processing requires a capable engine. GD alone cannot retain tagged images in this workflow; unsupported or malformed profiles, CMYK/YCCK sources and unverified color declarations are left unchanged with an explanatory result. Tagged AVIF output requires an available Imagick verifier. RGB matrix/TRC ICC v2/v4 profiles are supported; this is not full ICC, HDR or CMYK conversion support. Plugin-generated sidecars and optimized-original candidates are checked before publishing or replacing an original. Backup and restore retain the exact original bytes. Previously optimized originals and fresh sidecars are not automatically re-encoded to repair historical color loss. Regenerate sidecars explicitly when needed; existing original repeat-protection remains active. WordPress PNG thumbnails and scaled images created by the standard Imagick editor also retain supported source ICC profiles, including when automatic sidecars are disabled. This path keeps the upload untouched and removes private thumbnail metadata so the writer can retain ICC safely. GD and custom image editors keep their existing behavior. This does not infer profiles for existing untagged thumbnails; regenerate from an original that still has its profile. Core publishes its generated sizes; arbitrary image-writer faults are not covered by the optimizer candidate verifier.

Yes. Each format has its own quality setting. Both start at 82; existing installations inherit their previous shared quality until separate values are saved. The same number is not an equivalent visual-quality target across codecs or image engines. Original JPEG quality remains separate. For PNG sources, optional lossless WebP uses cwebp at moderate fixed effort, and optional lossless AVIF alpha uses avifenc with one worker. WebP preserves meaningful RGB and alpha values; hidden RGB in fully transparent pixels is not guaranteed. AVIF color remains lossy at the selected AVIF quality while its alpha channel is lossless. These modes are source-format rules, not automatic graphics or photograph detection, and do not affect JPEG sources. The optional profiles require their native encoder and PNG sources of at most 8 bits per channel. If an encoder is disabled, unavailable or fails, the requested profile fails safely without silently using a lossy fallback. Existing sidecars remain intact. Supported ICC profiles and the private-metadata policy still apply. Processing can cost more CPU or produce larger files; the existing skip-larger setting still applies. No universal size saving or full perceptual-quality guarantee is implied. The optional Imagick AVIF chroma setting requests 4:4:4 color detail only when the plugin's Imagick editor creates an AVIF sidecar. It does not switch engines or change native encoders, GD, independent custom editors, original optimization or core thumbnails. The default leaves encoder behavior unchanged. Supported writers can preserve finer colored edges, but output size, CPU and memory use may increase substantially on large images; test your images first. This is an encoder request, not a guarantee for every ImageMagick build, and does not make alpha lossless. If setting the request fails, generation fails without replacing an existing sidecar. Changing settings does not re-encode fresh sidecars or repeat original-file optimization. Use explicit force processing to regenerate sidecars after reviewing test images. Default profiles continue to use the existing supported-engine fallbacks.

New backups remain outside the document root in the current site's backup directory. Backup roots must not overlap the WordPress directory or uploads, including uploads configured outside WordPress. The local backup filesystem must support hard links, and original replacement requires safe rename within the upload directory. If safe publication is unavailable, the operation fails without overwriting the current original. Independent WordPress installations must use separate backup roots, including when configuring a custom backup directory.

Restore accepts only private or legacy backup references matching the source upload. The configured uploads root may be a symlink, but symlinks below uploads or a site's backup directory are rejected. Copies are verified before replacing an original; failed originals keep their sidecars and tracking. If an original is restored but sidecar cleanup fails, the result reports partial failure. This does not provide automatic recovery of database state after a process stops following file replacement.

Yes. Browser batches and WP-CLI queue commands share a saved snapshot of attachment IDs and cumulative progress. Reload the optimizer page and choose Resume. Pause stops further batches in that tab after its active request; another tab or CLI worker can still continue the same run. Deleted attachments are skipped and later uploads wait for the next run. Force is fixed for a run; an interrupted running item retries without force. Legacy queues retain completed items, but historical file-operation counters are unavailable.

Plugin optimization, backup/restore, sidecar cleanup and queue mutations share a process-held filesystem lock. A busy request reports contention instead of modifying media or resetting progress. Automatic upload optimization leaves metadata unchanged when busy; a later manual run can process it. The uploads directory must remain stable and support native cross-process flock on a local POSIX filesystem. The inert .yoohw-media-optimizer.lock file must remain in place, including after uninstall. Stop workers before updating the plugin or changing uploads configuration. Shared multi-host storage, overlapping older plugin workers and external WordPress/manual file changes are not coordinated. A process interruption after publishing a file but before saving tracking is not an atomic file/database transaction.