JPKCom DB

Graphic Editor — Tips & Tricks

Tricks for the Graphic Editor: WebP vs. AVIF vs. PNG/JPEG, quality vs. file size, client-side privacy, and combining it with other JPKCom tools.

Back to the overview: Graphic Editor · Open the tool live: www.jpkc.com/tools/graphic/

The manual explains every feature; the examples show the workflows. This page is about the surrounding judgment: which format is right when, how to weigh quality against file size, what client-side processing means for your privacy, and how the Graphic Editor plays with the other JPKCom tools. The interface is in English, so real button names are quoted as-is.

Choosing the right format

Four output formats, four purposes. A rough decision guide:

  • AVIF — the strongest compression, the smallest files. First choice for photos and hero images on the web where every kilobyte counts. In the tool, 80% (Recommended) is often enough for excellent quality. Catch: not every browser exports AVIF via the canvas — if the AVIF button is grey, switch on Use WASM Codecs in the result dialog and the tool encodes AVIF locally itself.
  • WebP — the pragmatic standard: supported almost everywhere, noticeably smaller than JPEG/PNG, with a lossless option for graphics. 85% (Recommended) is the sweet spot. If you don't want to decide, WebP is rarely wrong.
  • JPEG — the compatible choice for photos when maximum support for old systems matters. 85% gives good quality at a small size; no transparency.
  • PNG — lossless, for graphics with hard edges, text, logos, and anywhere transparency is needed. Files are large; if you want lossless and smaller, use WebP Lossless instead.

Rule of thumb: photo for the web → AVIF or WebP. Graphic/transparency → PNG or WebP Lossless. Maximum compatibility → JPEG.

Weighing quality against file size

  • The "Recommended" steps are good starting points, not law. JPEG/WebP 85% and AVIF 80% look flawless in most cases. Go lower (70%, 60%) when the image is shown small or the file size is critical — and check the result in the Result dialog with your eyes.
  • Scale first, compress second. The biggest saving is usually the right pixel size, not the last quality step. Crop and scale via Max Width / Save Resized to the size the image is actually displayed at before you touch quality. Pica produces a clean, lightly sharpened result (see Example 1).
  • The converter's live estimate helps. The Image Converter shows Estimated Size and Savings before export — good for weighing format and quality against each other. The number is a rough estimate; in WASM mode you get the Actual Size as a hard value after encoding.
  • WASM codecs often squeeze out more. MozJPEG, OxiPNG, libwebp, and libavif frequently compress harder than the browser's default encoding at the same visible quality. For OxiPNG the Optimization Level, for WebP the Method, and for AVIF the Speed control the effort: higher steps take longer but push the file smaller.

Pitfalls from practice

  • JPEG has no transparency. Export a transparent PNG as JPEG without setting a background color and the see-through areas get filled — usually not the way you want. Activate the Background color first (see Example 6). WebP and PNG keep transparency.
  • The editor scales width-first. In Export Settings, Max Width is the field that counts; the height follows the aspect ratio. If you need an exact height or a fixed size in both directions, use a Size Preset or Fixed Crop Size — those set width and height.
  • The converter only scales down. Max W / Max H in the Image Converter shrink but never enlarge beyond the original. A small image won't become a large sharp one — upscaling brings back no detail.
  • Metadata is lost. Because the export is a freshly rendered image, EXIF/IPTC data (camera, GPS, copyright fields) is not preserved. For privacy that's a plus; if you need the metadata, keep the original separately.
  • Very large images cost memory. There's no hard file limit, but processing runs in the browser's RAM. Huge sources (many megapixels) can make the editor sluggish — scale down roughly first, then fine-tune.
  • AVIF button grey? That's the browser, not your image. Turn on Use WASM Codecs and AVIF export works locally.

Privacy: why "in the browser" really matters here

The Graphic Editor loads, edits, and encodes everything locally in your browser — no upload, no server, no API; the WASM codecs compute on your device too. That's more than a technical detail: you can crop and convert confidential screenshots, client material, contracts, or private photos without handing them over. Online image converters, by contrast, upload your material to someone else's server. When confidentiality matters, client-side processing is the deciding argument — and the dropped EXIF record (see above) also means no GPS or camera info lingers in the exported image.

Combining with other JPKCom tools

  • Need a background or brand color? Get it from Colors — there you can extract a palette from an image or pick an exact color value — and set that exact value in the Graphic Editor as the Background color for the export.
  • Placeholder images to practice with or as layout fillers? The Placeholder Service quickly creates dummy images with any dimensions and colors to rehearse the crop and convert workflows.
  • Image ready for social sharing? Use the Meta Tags Generator to produce the matching og:image tags including dimensions for the graphic you just cut to social size here.

More context: the overview for the big picture, the manual for every feature, and the examples for the step-by-step workflows. You can try all of it in the tool.