Application image guides

Pixels, KB and DPI: which upload requirement are you changing?

Understand image dimensions, file size and resolution metadata with worked examples, and learn which FormAssets controls can change each one.

FormAssets · Reviewed

This is technical preparation guidance, not an application authority’s approval. Your current official notice and upload screen take precedence. Numerical examples below are illustrative, not universal requirements.

The short answer

Pixels describe the image’s width and height. KB describes how much storage the encoded file occupies. DPI describes a resolution value associated with physical size. They are different checks: a small file can have the wrong dimensions, and an image with the right dimensions can still exceed the upload limit.

Pixel dimensions
A 200 × 230 image is 200 pixels wide and 230 pixels high. Reversing those numbers creates a different shape. Resizing changes this pixel grid; cropping changes which part of the source appears in it.
File size
The stored bytes depend on the format, image detail, compression and metadata. There is no fixed conversion from 200 × 230 pixels to a particular number of KB.
DPI or resolution metadata
A density value can associate pixels with a physical length. Changing the density field alone does not add detail to a blurry picture or change its pixel dimensions.

A worked example: why one passing check is not enough

Suppose an upload screen asks for a JPG, 200 × 230 pixels, between 20 and 50 KB. Those are four requirements: format, width and height, lower size bound, and upper size bound.

Use the numbers shown by your own portal. This example is not a recommendation to resize every application photograph to 200 × 230.

What “50 KB” means in FormAssets

FormAssets currently calculates one displayed KB as 1,024 bytes. Entering 50 allows up to 51,200 bytes. A receiving service using a 50,000-byte limit would be stricter. A rounded size display also cannot prove that a file is under a boundary.

If the portal specifies a byte limit, compare bytes directly. For an upper limit of 50,000 bytes, a FormAssets setting of 48 KB caps output at 49,152 bytes. That is an illustrative upper-limit workaround, not a rule for portals with a narrow minimum-to-maximum range. Check both bounds before changing the setting.

When physical dimensions and DPI matter

For a hypothetical instruction of 2 inches wide at 200 pixels per inch, the corresponding width is 2 × 200 = 400 pixels. If centimetres are specified, divide centimetres by 2.54 before multiplying by the density. This arithmetic does not tell you which values a portal accepts: an instruction that separately specifies pixels must also be followed.

The generic FormAssets resizers do not offer a DPI control. Do not use them as proof that a 200-DPI requirement has been met. Application presets can write DPI metadata when their configured rules require it. Browser canvas exports normally use 96-DPI resolution metadata where the format supports it; see MDN’s canvas export documentation.

Choose the control for the actual problem

  1. Open the photo resizer for custom pixel dimensions and an upper file-size limit. Enter width and height in the correct order.
  2. Choose “Fill frame, crop edges” only when the crop keeps all required content. Choose “Fit all, add white space” when preserving the whole image is more important and the receiving rules allow the resulting margins.
  3. Set “Maximum file size (KB)”, then choose your image and select “Prepare JPG”. The tool seeks an output under that ceiling; it does not promise an exact KB value.
  4. Download and open the JPG. Inspect legibility as well as the reported dimensions and size. The generic tool does not enforce a portal-specific minimum size.

For a supported application with a minimum size or DPI rule, inspect its source-linked preset and current official instructions instead. A numerical pass is preparation evidence, not a submission receipt.