Image quality workflow
How to Check a Reference Image Beyond Its Thumbnail
A thumbnail helps you remember which picture you meant to check; it is a poor basis for judging small text, edge detail or an export defect. A practical two-stage workflow is to locate the candidate in a small board, open the original in a browser or image viewer, record what you found, and return to the task. The archival FloatBoard clip illustrates the small-board and history stage only. It should not be mistaken for a demonstration of a full-size viewer inside the app.
Decide which detail matters before zooming
Ask what the image must prove for your task. Is a button label legible? Does a thin border disappear? Are two crops truly the same composition? Different questions need different originals and different zoom levels. A thumbnail can help you find the candidate, but it compresses away the very details you may need.
For a UI review, write a precise question such as Is the focus outline visible around the primary button at normal display size? Save the original screenshot file and its app version or date. For an art reference, note whether you care about shape, lighting or texture. If you only need a rough composition cue, a small tile may suffice; if you need exact evidence, open the source.
The archival GIF shows thumbnail tiles and a history panel. It does not show reliable full-size validation, so the steps below use a browser or image viewer for that part.
Find the actual source file, not an enlarged preview
Locate the original image in your project folder or on its source page. A browser-generated preview, messaging-app thumbnail, or screenshot of a screenshot may have been resized or recompressed. Compare the file name, dimensions and date with the candidate on your board. If you no longer know which original produced the tile, treat the image as unverified until you can trace it.
For a web image, return to the publisher's page and record its URL and usage terms. For a product screenshot, use the file created during the test, not a version pasted into chat. Give the original a descriptive name such as settings-focus-outline-linux-2026-10-05.png. Keep that name with your task note so another reviewer can inspect the same evidence.
A copied image in clipboard history may be useful for navigation, but it is not a substitute for knowing the authoritative source.
Inspect at the size that answers the question
Open the original in a browser tab, system image viewer or editor. First view it at 100% or actual pixels if the tool offers that control, then fit it to the expected display size. At 100%, check the small feature you care about: edge, glyph, cursor, crop boundary or artifact. At the target size, check whether the issue remains visible to a normal viewer. Record both observations if they differ.
For a screenshot of an interface, do not mistake browser zoom for image resolution. Zooming a low-resolution preview only makes its pixels larger. If a claim depends on exact text, read it in the source app when possible. If a claim depends on color, use a suitable calibrated workflow rather than a floating thumbnail. A viewer can expose detail; it cannot restore information absent from the file.
When comparing two exports, use the photo comparison guide for synchronized questions about crop, sharpness and detail.
Write down one observation before returning to work
After inspecting the original, write a short result tied to your initial question: Focus outline is visible at 100%, but it disappears against the dark background at the target scale. Add the original file name and relevant version. If the result is uncertain, say so. For example, Cannot assess because this is a 640-pixel preview; request the original export. That is more useful than silently choosing the better-looking thumbnail.
Keep the result in the project issue or document. A brief FloatBoard text card can remind you of it while you edit, but it should not be the only place where the observation exists. If the image is confidential, keep both the original and note in approved storage, and clear the temporary display before a screen share.
This loop turns a visual impression into a reproducible finding without pretending that the board itself measured image quality.
Return to the board with a smaller, labelled set
Close or minimize the full-size view, then return to the design, editor or report. Keep only the candidate that informs the next step, plus a short label such as original checked; border needs stronger contrast. Remove stale tiles that could be mistaken for approved images. The board's advantage here is continuity: you can see what you checked while you make the change.
If you need to refer to a recent text copy, a history panel may help retrieve it. The GIF's history view is not proof that a given image remains there in every current version, so keep source files outside the app. If your work needs dozens of annotated originals, a dedicated asset-management tool is better suited to search and audit.
The image-reference guide explains how to keep a small design shortlist; this guide is about verifying one candidate beyond its preview.
Example: verify a screenshot before filing a bug
Suppose a QA reviewer adds a screenshot tile to a board because an icon seems clipped. Before filing a bug, they find the original PNG and check whether the icon is actually cut off at 100%. The first thumbnail looked suspicious because the tile cropped the edge. In the original, the icon is intact, but at normal window size it is too close to the panel border. The accurate report is therefore about spacing at the target layout, not a broken PNG.
The reviewer saves the original PNG in the issue, notes the screen size and app version, and keeps one small reference on the board while adjusting padding. If the icon were clipped in the original instead, the same process would point to a different cause. Either way, the full-size check prevents a misleading report based on a preview.
This is a fictional example of the method, not a claim that the archived recording shows this particular bug.
Know when even the original is insufficient
An original screenshot can still omit what happened before capture, the system zoom setting, or an interaction state. For an accessibility or responsive-layout issue, reproduce the behavior in the application when possible. For a photographic asset, the original file may still lack rights information or a trustworthy color profile. Ask for missing context rather than inferring it from pixels.
FloatBoard's current free plan provides five images and five texts per day in one window. The archival clip displays a larger set; it may represent an older setup or a different plan. Neither the tile count nor a history view in that clip changes the current limits.
Use the board as a navigation aid, the original as visual evidence, and the project record as the place for conclusions.
Questions about image thumbnails and originals
Can I judge image sharpness from a thumbnail?
No. Open the original file and inspect it at an appropriate scale. A tile may be resized, cropped or compressed.
Does FloatBoard provide the original image file?
Do not rely on a board tile as your authoritative source. Keep the original in your project folder or return to the source page, then record its path or URL.
What if the original and thumbnail look different?
Check whether the preview was cropped or scaled, and whether you opened the correct source file. Judge the detail using the original and actual target layout.
Should I keep every image after checking it?
Keep the originals your project needs, but remove irrelevant temporary tiles from the visible board. A labelled working set is easier to use than a large unreviewed wall.