Image Resizer for Online Forms

Online forms do not all use the same image specification. One may ask for an exact width and height, another may allow a range of dimensions, and another may care mainly about a maximum or minimum file size. Instead of choosing a generic exam or passport preset, copy the current instructions from the destination and use those values.

You can paste requirement text, let local OCR read an English-language screenshot, or enter the rules manually. Parsed text is shown back to you for confirmation so a valid-looking OCR mistake is not silently treated as an approved requirement.

An uploaded image can be inspected even before you confirm a set of rules. The source summary reports its detected format, pixel dimensions, file size, reduced aspect ratio, megapixel count, orientation, transparency and DPI metadata when that metadata is present.

Once requirements are confirmed, the same source facts become a diagnosis: a rule can already pass, need a change, require your review, or be blocked when the requested combination cannot be satisfied safely.

Pixel dimensions and file size describe different properties. A 600 × 800 image can still exceed a 200 KB limit, while a very small file can have the wrong width or height. Matching one value does not prove that the other rule is satisfied.

Oliv ez plans the dimensions and byte limit together. Exact dimensions, minimum and maximum width or height, and inclusive minimum or maximum file-size rules are checked separately against the final file.

If a portal says 'maximum 50 KB', the useful goal is a file at or below that ceiling—not an arbitrary file that is exactly 50 KB. If it says '20–300 KB', both the minimum and maximum matter. Olivez keeps these as an inclusive byte range and validates the downloadable result against it.

The parser distinguishes decimal KB and MB from binary KiB and MiB instead of treating the units as interchangeable. When a minimum file-size rule is met with non-visual container padding, the result says so because extra bytes do not create extra image detail.

A portal may require one format, allow several formats, or say nothing about format. If the source format is already allowed, Olivez preserves it instead of converting without a reason. If exactly one different format is required, conversion can be planned.

When several formats are accepted but the source is not one of them, you choose the output format. That avoids hiding the trade-off between JPEG compression and transparency versus a potentially larger PNG. Converting transparent pixels to JPEG also requires a solid background decision.

Changing width and height independently can distort a face, signature, logo or product image. Olivez keeps proportional geometry and asks you to choose the framing when an exact aspect ratio or exact dimensions require a crop.

The crop is not treated as a background operation. You position the image, adjust zoom and confirm the part to keep before the planner can continue.

A minimum-dimension rule can be larger than the source image. Olivez can enlarge the image only after you acknowledge that resizing cannot recover detail that was never present in the original.

The resulting pixel dimensions can pass a measurable rule while visual sharpness still needs human judgment. For an important application, begin with the clearest original you have instead of repeatedly enlarging or recompressing an already processed copy.

Some scanned-photo or print-derived instructions specify DPI or PPI in addition to pixel dimensions. Olivez reads supported DPI metadata from the source, can write a confirmed exact DPI value, and checks the metadata again in the finished file.

Changing DPI metadata does not create pixels, restore focus or improve a low-resolution photograph. When a destination only specifies digital pixel dimensions and file size, do not invent a DPI requirement that the destination never asked for.

The same workflow can be used for an application photograph, scanned signature, logo, product image or another static JPG, PNG or WebP when the destination gives measurable upload rules. You do not need a dedicated preset for each exam, employer, university or website.

This is especially useful when the instructions combine several conditions—for example JPG only, a range of acceptable dimensions and a 20–300 KB file-size range. Enter the current rules from the actual portal rather than relying on a remembered requirement from an older application cycle.

Format, actual encoded bytes, width, height, exact aspect ratio and supported DPI metadata are machine-checkable. The finished file is reopened and these measurable properties are checked again before it is offered as a successful result.

Visual or policy rules are different. A plain background, face position, glare, blur, signature clarity, photo recency, color-space requirement or another unsupported instruction is kept visible for manual review rather than being labelled as verified. A technically valid file can still be rejected by hidden server rules or human review.

If the source already satisfies every confirmed measurable rule, the workflow can return the original file unchanged instead of re-encoding it. That avoids introducing unnecessary compression loss or metadata changes.

When changes are needed, the plan is shown before processing so you can see whether the tool intends to crop, resize, convert format, write DPI metadata or adjust the file-size range.

Requirement parsing, English screenshot OCR, image inspection, crop decisions, processing and validation run in your browser. The selected source image and requirement screenshot are not sent to an Olivez image-processing service.

The result is not trusted merely because an encoder finished. Olivez examines the actual encoded bytes, detects the output format and dimensions again, checks container completeness, file size, aspect ratio and requested DPI metadata, and blocks the download when a confirmed measurable requirement fails.