How to verify web design files

What “verifying” web design files really means

People use the phrase for four different jobs, and it helps to separate them because each has its own test. First, are the files intact: did the archive download or transfer without corruption, and are they the exact files the sender meant to send? Second, are they complete: is every page, stylesheet, script, image and font that the pages refer to actually in the folder? Third, are they valid: is the HTML, CSS, JavaScript, JSON and SVG written correctly so that browsers read it the way the author intended? Fourth, are they right: does the finished page match the approved design in colours, fonts, spacing, images and behaviour on different screen sizes?

You rarely need all four for a small job, but for a paid project, a redesign or a launch, running all four takes under an hour and catches most of the problems that otherwise appear after the site is live.

Verify in this order: intact, complete, valid, right. A corrupted or incomplete folder makes every later check misleading.

Step 1: Check the files arrived intact

Start by confirming that you received what was sent. Open the archive (ZIP or similar) and make sure it extracts without errors. Compare the number of files and the total size with what the sender expected. If the sender supplies a checksum, you can prove the files are identical to theirs.

A checksum, also called a hash, is a short fingerprint calculated from a file's contents. If even one byte changes, the fingerprint changes completely. SHA-256 is the usual choice. Ask the sender to calculate the SHA-256 of the archive and send it separately, for example in a message rather than inside the archive, then calculate it yourself and compare the two values character by character.

• macOS or Linux terminal: shasum -a 256 your-file.zip (or sha256sum your-file.zip on Linux).
• Windows PowerShell: Get-FileHash your-file.zip -Algorithm SHA256.
• In your browser: the Hash Generator on this site calculates SHA-256 for a file locally, without uploading it.

Step 2: Check nothing is missing

A page can look fine on the designer's computer and break on yours because a file it needs is not in the folder. Open the main page directly from the folder in a browser, then open developer tools (F12, or Cmd+Option+I on a Mac) and look at two places. The Console tab lists errors such as scripts that failed to load. The Network tab lists every file the page asked for, and anything that could not be found is shown in red with status 404.

Missing files usually have one of a few causes: a path written with the wrong capital letters (some servers treat Logo.png and logo.png as different files, although many laptops do not), a file that was never exported, a font that is referenced but not included, or an absolute path such as C:\Users\name\design\hero.jpg that only exists on the original computer. Click each red entry and fix the path or ask for the file.

Also compare the folder against the agreed deliverables. For a typical site that means every page template, the main stylesheet, scripts, images in the formats you need, the fonts or a note of where they are loaded from, a favicon, and any source design files you are entitled to receive.

Step 3: Validate the code

Code that mostly works can still contain mistakes that behave differently from browser to browser. Validation catches them early. Use the checker that matches each file type.

Do not chase a perfect report. Aim for no errors that change how the page renders or behaves, and understand any warning you decide to leave.

Step 4: Check images, icons and other assets

Also check the small assets that are easy to forget: a full favicon set, a social sharing image, and a text alternative (the alt attribute) for every meaningful image.

• Format: photographs suit JPG or WebP, logos and icons suit SVG or PNG, and anything with transparency needs PNG, WebP or SVG.
• Dimensions: an image should be close to the size it is displayed at, with enough extra pixels for high-density screens. A 4000-pixel photo shown in a 400-pixel box wastes bandwidth.
• File size: large files slow the page. Compress and resize before publishing; the Image Compressor, Image Resizer and Image Converter run in your browser.
• Metadata: photos can carry camera details and GPS location. Remove it from anything you publish with the Remove EXIF Metadata tool.

Step 5: Check the build matches the design

A simple way to spot drift is to put a screenshot of the design over the page at about half opacity and look for edges that do not line up. Most design tools also have an inspect panel that lists the exact spacing, colour and type settings for a selected element, which you can compare with the page.

• Colours: pick the exact value from the design file or an exported image, and compare it with the CSS. The Color Converter shows the same colour as HEX, RGB and HSL, and the Color Picker from Image reads a pixel's value from a screenshot.
• Fonts: in developer tools, select a heading, open the Computed panel and check the font family, size, weight and line height. Make sure the font file is actually loaded and not silently replaced by a fallback.
• Spacing and sizes: use the box-model diagram in developer tools to read margins and padding. If the design is in pixels and the code uses rem, the PX to REM Converter helps you check the numbers.
• Layout at different widths: resize the window, or use the device toolbar in developer tools, and test typical widths such as a small phone, a large phone, a tablet and a desktop. Look for text that overflows, images that stretch and buttons that become too small to tap.
• States and behaviour: hover, focus, active and disabled states, menus, forms and error messages, because static mock-ups often leave these out.

Step 6: Quick accessibility and performance checks

Two short checks catch problems that a visual comparison never will. The Lighthouse panel in Chrome developer tools audits a page for performance, accessibility, best practices and search basics, and gives a list of specific issues to fix. For accessibility, make sure text has enough contrast with its background: the WCAG guidelines ask for a ratio of at least 4.5 to 1 for normal text and 3 to 1 for large text. Then try the page with the keyboard alone: you should be able to reach every link, button and field with the Tab key and see where the focus is.

Step 7: Check what the files send and load

Finally, look at what the page does behind the scenes. In the Network tab, list the requests and check that every script, font and tracker comes from a source you expect. Unknown third-party scripts are a common surprise in template-based designs. If you are handling a site that accepts file uploads, or a tool you want to trust with private documents, our guide on how to check whether a website uploads your files explains the Network tab and the airplane-mode test in detail.

A checklist to sign off a web design delivery

• The archive extracts cleanly and its SHA-256 matches the sender's.
• Every page, stylesheet, script, image and font the pages refer to is present, with no 404 errors.
• There are no errors in the browser Console on any page.
• HTML, CSS and JSON or SVG files pass validation, apart from warnings you have accepted.
• Images use suitable formats and sizes, have alt text and carry no private metadata.
• Colours, fonts and spacing match the approved design on the main templates.
• The layout works on small, medium and large screens, and in the browsers you support.
• Text contrast and keyboard access are acceptable.
• All third-party requests are known and intended.
• You have the source files and licences you were promised, including font licences.

Try these checks on our tools

Several of the checks above can be done in your browser without installing anything. The Hash Generator calculates SHA-256 for a downloaded file, the JSON Formatter and XML Formatter pinpoint syntax errors, the CSS, HTML and JavaScript minifiers show how much a file shrinks, and the image tools compress, resize, convert and clean pictures. These tools run locally, so the files you are verifying are not uploaded.

Frequently asked questions

Try these tools