How to use Compress WebP
Choose one genuine WebP file or drag it into the upload area. The published limit is 25 MB, and the compressor rejects empty files, mismatched formats, corrupt structures, and unsafe containers instead of producing a download with a convincing extension. After selection, review Light, Balanced, and Strong before starting.
Choose “Compress WebP” and wait for both compression and output validation. Success reports the original bytes, compressed bytes, bytes saved, and percentage saved. Download the new file, open it in the application used by the recipient, and keep the original until that check is complete. Compression never overwrites the selected source.
- Select one supported source file.
- Choose a preset for the final use.
- Run compression and review the measured savings.
- Download, open, and inspect the result before replacing anything.
How Compress WebP actually reduces bytes
WebP input is decoded and written back as genuine WebP. Light uses lossless WebP, while Balanced and Strong use the format’s lossy encoder with higher effort and smart chroma subsampling. The output is decoded again to confirm the same width, height, and format before it becomes downloadable.
A smaller extension alone is not evidence of compression. Chanjify measures the exact input and output byte lengths after a real encoder or package writer finishes. It then reopens or reparses the result using the relevant format library. Only a candidate that is valid and smaller than the source reaches the download state.
Light, Balanced, and Strong presets
Light is best for graphics that must not lose pixel information, though it may not beat an existing lossy file. Balanced uses quality 78 for ordinary websites. Strong uses quality 62 for thumbnails, previews, or restrictive content systems. None of the presets silently changes the output to JPG or AVIF.
Balanced is selected by default because it aims for a useful reduction without making the strongest tradeoff. Presets are deterministic settings, not vague promises about a target percentage. Source content controls the result: flat graphics, noisy photographs, repeated XML, and already compressed media all respond differently.
What Already optimized means
When a valid candidate is the same size or larger, the result says Already optimized and shows both sizes. The tool does not replace the source with a larger file, fabricate a savings percentage, or relabel unchanged bytes as compressed. You can try another preset, but stronger is not guaranteed to help every format or source.
This state is common with tiny files, modern encoder output, archives already written at a high ZIP level, and documents dominated by media that the safe engine does not alter. It is a useful result because it prevents unnecessary generation loss and avoids an unhelpful download.
Quality and structure considerations for WebP
Re-encoding a previously compressed WebP can make artifacts more visible. Animated WebP is not supported by this focused single-image workflow. Older applications may have weaker WebP support, and lossless mode can be larger than a well-tuned lossy original, in which case the honest result is Already optimized.
Always inspect what the format makes meaningful: photographic texture and edges for lossy images, transparency and gradients for PNG, paths and filters for SVG, selectable text and page count for PDF, or sheets, slides, styles, formulas, and relationships for office packages. Automated validity checks complement rather than replace that destination review.
Practical uses
Typical uses include reducing modern web assets, blog illustrations, product photography, documentation media, and app bundles that already standardize on WebP and therefore cannot accept a different image format.
A repeatable workflow is safer than compressing the only copy. Preserve a master, create a clearly named compressed derivative, and record which preset was used when a team needs reproducible outputs. Test one representative file before processing a larger collection so project-specific fonts, profiles, media, or application extensions are discovered early.
Privacy and processing location
Raster image compression uses Chanjify’s own validated Sharp route. The file is decoded and re-encoded in memory, returned immediately, and is not intentionally written to permanent storage.
No third-party conversion service is used. Server routes apply request-size and format limits, work with in-memory buffers, send the result in the same response, and do not intentionally create an upload directory or conversion history. Browser routes hold data in the active page. Hosting infrastructure may still process ordinary request logs as explained in the Privacy page.
Defensive validation
Files are untrusted input. Image routes inspect magic signatures and bound decoded pixels. SVG markup must parse with an SVG root and is never injected into the interface. PDF input must have a PDF signature and load successfully. Office ZIP packages are checked for traversal paths, excessive entries, unreasonable declared expansion, suspicious compression ratios, and required format structures.
The output receives another check before success. Raster dimensions and format must match, SVG must parse again, PDF page count must remain stable, and office packages must retain required entries and reopen through a relevant parser. Errors are caught and described without exposing a local path, stack trace, or internal server detail.
Metadata, signatures, and compatibility
Image metadata is removed by default because camera location, device details, thumbnails, and color profiles can add bytes or reveal information. Use the visible metadata option when those records are required, then expect a larger result. Office package signatures and PDF digital signatures can be invalidated by any byte-level rewrite even when visible content remains unchanged.
Use a current browser and the real destination application for final testing. Advanced color profiles, specialist TIFF variants, interactive SVG, encrypted PDFs, signed office packages, macros, external objects, or application-specific extensions can fall outside the safe supported path. The compressor reports a failure rather than claiming success when validation cannot support the output.
A dependable Compress WebP checklist
Confirm the source opens normally, check that its real format matches WebP, select the least aggressive preset that satisfies the delivery limit, and compare a representative detailed area or document feature afterward. Record the reported byte savings rather than estimating from a rounded file-manager label.
Keep the master file, use the “-compressed” filename for the derivative, and avoid repeated lossy compression of the same derivative. If the result is Already optimized, treat that as a correct finding and consider a different delivery format only when the receiving system allows it. Related tools below provide explicit conversions; this compressor itself keeps the promised format and structure.