Images & photos · Browser Image & Drawing Editor
Pixels vs DPI: why an image editor cannot add resolution to a photo
· Background
image-editing canvas browser-processing
A printer asks for 300 DPI, a designer asks for more pixels, and the two requests are related but not the same. This post untangles pixel dimensions from print density and explains what an editor can and cannot change.
The '300 DPI' request that stalls a print job — the vocabulary clash between screen people and print people
The phrase 'make it 300 DPI' often hides two different jobs: deciding how large a print should be, and changing information stored in an image file. Start with the physical request. Ask for the finished width and height, then inspect the editor's actual pixel dimensions. This application reports and changes pixel width and height, but it has no DPI field and does not preserve a print-density instruction by contract.
That makes the next action concrete. Crop away unwanted edges only when the remaining pixel grid still meets the print requirement, and keep the original before experimenting. The editor can change the rectangle and resample layers, but it cannot create detail that the camera never sampled. Density metadata in particular belongs to file-format tooling outside the evidence for this editor.
Pixels are the picture; DPI is an instruction — how a photo's real content is its pixel grid and density is a note about how to spread it on paper
Pixels are the sampled picture: they carry the edges, texture, noise, and colour values that the image contains. DPI is a density instruction used to relate that grid to a physical measurement. Changing the instruction can change the proposed print size without changing a single pixel. Conversely, resizing changes the grid itself, and cropping removes pixels outside the selected rectangle.
For this reason, print suitability should begin with pixels and inches rather than with a field label. If a printer asks for a target density, calculate whether the available width and height can cover the requested size. The browser editor exposes no density-metadata control. It is useful for preparing the visible raster, not for pretending that a metadata edit has added photographic resolution.
Where DPI lives in a file — the density fields in JFIF and the pHYs chunk in PNG, and why changing them alters no pixel
Some image formats have places for physical-density information, but the exact fields are format context rather than a feature established by these editor sources. The important operational boundary is clear: this application does not read or edit a DPI value. Its document model works with image dimensions, layers, crop rectangles, and canvas pixels. Do not infer a metadata editor from the presence of an export button.
A density-field rewrite, where supported by a dedicated format utility, would not sharpen a face, restore a small caption, or recover texture lost during capture. It would only change how another program interprets the relationship between pixels and physical size. Here, prepare the raster with the tools the editor actually exposes, then use a specialised packaging step if a downstream print system requires metadata.
Density metadata is format context, not a field this editor reads or edits
The arithmetic is modest but decisive: print density is pixel count divided by physical inches. A 3,000-pixel-wide image placed across 10 inches works out to 300 pixels per inch on that calculation. Stretch the same file across 20 inches and the calculated density halves. Nothing about the image bytes automatically becomes more detailed because the requested physical size changed.
Use both dimensions, not just the headline number. A landscape image may satisfy the width while failing the required height after cropping, and a portrait crop may remove more useful pixels than expected. The editor can crop to the composition and resize layers to an integer grid, but it has no DPI control. Check the final pixel dimensions against the printer's specification before delivery.
What cropping and resizing do to this — cropping removes pixels, resizing resamples them, and neither creates genuine detail
Cropping and resizing answer different questions. Cropping keeps a smaller part of the existing grid, so every discarded border pixel is gone from the working result. Resizing asks the browser to draw the layers onto a requested integer grid, which resamples existing information. Both operations can improve composition or fit a specification, but neither creates genuine captured detail.
Work non-destructively at the decision point: save the source, test the crop, and compare the resulting dimensions with the job's physical size. If the grid is too small, enlarging may produce a file with more pixels but not more evidence. If the grid is too large, downsampling can be sensible, but the export still needs inspection. The editor changes pixels, not DPI metadata.
Worked example: checking whether a phone photo can print as an A5 flyer — from pixel dimensions to a yes or no
Take a phone photograph and imagine an A5 flyer. First record the source width and height in pixels. Then decide the flyer orientation and reserve any border or text area, because the useful crop is smaller than the original frame. Divide the remaining pixel dimensions by the requested physical dimensions. That calculation gives a practical yes, borderline, or no before you export.
Suppose the crop leaves 2,480 pixels across and the flyer needs 8.27 inches across: the arithmetic is about 300 pixels per inch before any printer-specific allowance. If your crop leaves substantially fewer pixels, the editor cannot repair the deficit by assigning a DPI value. Crop and resize only to prepare the visible raster, then confirm the final dimensions and requested print workflow with the printer.
Worked example: divide known pixel dimensions by the requested print size
This discussion does not establish an upscaling algorithm, a printer hardware resolution, a paper profile, or a colour-management pipeline. Those systems may affect the final physical result, but they are outside the browser editor’s documented pixel operations. The editor has no DPI field, and its sources do not justify a promise that an export is print-ready for every device, stock, or production workflow.
It also does not turn a density calculation into a guarantee about sharpness. A printer may apply its own screening, a service may impose bleed and safe-area requirements, and a colour-managed workflow may need different evidence. Use the editor for the local crop or annotation it actually performs, preserve the original, and hand the resulting pixel dimensions to the process that owns the print specification.
Takeaway: count pixels first — how the Browser Image & Drawing Editor lets you crop to the pixels you need without pretending to add more
Count pixels first, and let the physical requirement determine whether the image has enough of them. The Browser Image & Drawing Editor can crop a local image, change its pixel grid through resizing, and export the visible result. It cannot edit DPI metadata, preserve a print-density instruction by contract, or manufacture detail that was absent from the source.
A reliable handoff is short: retain the original, record the source dimensions, calculate the post-crop density for the requested size, inspect the export, and pass the final pixel dimensions to the print workflow. That keeps the tool's promise precise. You are preparing a raster for a physical use, not changing an invisible number and calling the photograph higher-resolution.