How to Share an HTML Prototype with Clients

The most reliable way to share an HTML prototype is to upload the zipped static site to a dedicated viewer platform like LinkShip, generating a single trackable browser link with access controls rather than emailing raw files. Test that URL in Chrome, Safari, Firefox, Edge, and a mobile viewport before sending it, and give clients a short brief that explains what to review.

You've probably seen the same handoff fail in several ways. A client opens a ZIP archive and sees a folder full of files, opens index.html directly, and gets a page without styles. A font is missing, a JavaScript interaction works only on localhost, or two stakeholders review different attachments from different email threads. The prototype may be correct, but the delivery process makes it look unreliable.

The practical workflow is straightforward:

Package the complete static site, including HTML, CSS, JavaScript, images, fonts, and other required assets.
Upload the build to a static-site host and publish it over HTTPS at a stable browser URL.
Protect unreleased work with the access controls the service documents.
Test the client-facing address externally, across browsers, devices, keyboard navigation, and key flows.
Send the link with a version label, review goals, known limitations, and a structured feedback path.
Replace the underlying build only after recording changes, preserving the review URL when the platform supports replacement.

That approach turns a file handoff into a controlled review environment. It also follows the Web's original publishing model, where a document could be published once and opened remotely through a URL instead of distributed as an installed application. Tim Berners-Lee created the first HTML prototype and the WorldWideWeb browser on a NeXT computer in 1990, then introduced the browser to colleagues at CERN in March 1991. The first public HTML description appeared in 1991 and listed only 18 tags, a small foundation compared with today's browser-based experiences (HTML history).

Why Browser Links Beat File Attachments

Emailing a raw HTML file is tempting because it feels immediate. It works for a genuinely self-contained page, but that case is narrower than many prototypes. The moment the page depends on a stylesheet, image folder, font, JavaScript module, or correctly resolved route, the recipient needs the whole project structure and a browser context that behaves as expected.

A hosted link removes several points of friction at once. The client opens an address in a normal browser, without installing an application or learning which file to double-click. You control the published build centrally, so the client and the internal team can review the same version rather than comparing attachments with unclear filenames.

Practical rule: If a client has to ask which file to open, the handoff isn't finished.

A browser link also changes the unit of delivery. You aren't merely transferring files. You're publishing a reviewable experience with a defined address, a known build, and a repeatable way to return to it. Serving the prototype over HTTPS from a stable URL helps avoid the familiar “it works on my machine” problem, although it doesn't remove the need for browser and accessibility testing.

What the browser link solves

A client reviewing a checkout concept should be able to open the link, move through the intended flow, and understand which interactions are simulated. They shouldn't need to install Node.js, reconstruct a directory tree, unblock a downloaded script, or guess whether a blank screen is part of the design.

The distinction matters especially for remote reviews. One stakeholder may use a laptop while another opens the link on a phone. A hosted page gives both people the same starting point, while the review brief can tell them which device and flow to test.

The Web standards timeline reinforces this browser-first model. The W3C was formed in late 1994, HTML 3.2 was endorsed in January 1997, HTML 4.01 became a W3C Recommendation on December 24, 1999, and HTML5 development began in 2004 before standardization in 2014 (HTML standards history). The lesson for a prototype handoff is practical: publishing is only half the job. You must verify how the page behaves in the environments where clients will review it.

Preparing and Uploading Your Static Site

Start with the build, not the sharing service. A single HTML file is appropriate when the CSS and JavaScript are inline and images or other dependencies aren't required. A multi-page concept, branded landing page, or product flow usually needs a ZIP archive containing the complete static site.

A client-facing prototype should be published as a complete static site rather than an isolated HTML file when it depends on CSS, JavaScript, images, fonts, or other assets. The browser resolves those dependencies from the paths in the document, so a missing file or incorrect relative path can make a valid build appear broken.

Package the build deliberately

Before uploading, open the project from a clean copy rather than the development directory. Check that the entry page is where the host expects it, preserve the directory structure, and remove local-only references.

Resolve asset paths: Look for references that point to a developer's filesystem, localhost server, or a directory name that won't exist after upload.
Check filename casing: A path that works on one local environment can fail on a case-sensitive server if Hero.png is referenced as hero.png.
Include fonts and media: Confirm that web fonts, icons, videos, and image files are present and referenced with the correct relative paths.
Remove sensitive material: Delete API keys, tokens, customer data, internal comments, source maps, unused assets, and demo content that shouldn't reach the browser.
Compress what you can: Optimize oversized images and avoid unnecessary third-party scripts before publication.

The packaging decision also affects how clients perceive the work. A prototype with an intentionally simulated payment action should say so in the page or review notes. Resources such as 925 studios on prototyping can help frame the difference between validating an interaction and delivering production functionality.

Upload and inspect the published version

Upload the single file or ZIP to a static-site service, retain the expected folder structure, and publish the resulting browser address. If the service supports a custom slug, choose a short, recognizable path that identifies the project or review milestone without exposing confidential information. LinkShip's static site hosting guide is relevant for teams using a service that accepts a single HTML file or a zipped HTML, CSS, and JavaScript site, but current upload rules should always be checked in the product interface.

Don't approve the build from the upload screen alone. Open the final URL in a clean browser session, click through every primary route, submit each prototype form, trigger error states, and inspect the page at a mobile viewport. A locally working page isn't evidence that the uploaded version works.

Securing Unreleased Work with Access Controls

A prototype link is not automatically a secure prototype share. Browser-delivered HTML, JavaScript, source maps, assets, direct download paths, and old deployment URLs may remain inspectable or accessible even when the landing page is protected, a boundary that generic password advice often overlooks (prototype sharing security guidance).

Treat the exported site and the viewing permission as separate controls. First sanitize the package. Then decide who should be able to open the published address and how access should end.

Protect the package before publication

Anything sent to the browser should be treated as potentially inspectable. Don't place production credentials in client-side JavaScript, and don't connect an exploratory prototype to a live system unless the integration has been deliberately isolated. Replace real customer records with fabricated demo data, remove internal notes, and review source maps and unused files before uploading.

OWASP's file-upload guidance recommends validating the actual file type instead of trusting the Content-Type header, generating application-controlled filenames, enforcing filename and file-size limits, and permitting uploads only for authorized users (OWASP file upload guidance). For a prototype workflow, the equivalent discipline is to verify the package you publish and restrict who can upload or replace it.

Match the control to the risk

A password can stop casual exposure, but it doesn't establish fine-grained confidentiality by itself. For unreleased product work, consider whether the delivery workflow needs a password, an email allowlist, an expiry date, a view-count cap, or a way to revoke access without changing the address. Confirm the actual behavior of each control in the product interface, especially for nested routes and assets.

An access audit log can also answer a basic operational question, which stakeholders viewed the review build and when. That information is useful for follow-up, but it shouldn't be treated as proof that someone understood or approved the design.

Security boundary: If the browser can download it, assume a determined recipient can inspect or copy it.

The same principle applies after the engagement ends. Remove exposed demo data, disable or expire access where supported, and check whether old deployment URLs or cached assets remain reachable. A link that is hard to guess isn't the same as a link with verified authorization. For a broader treatment of permissions and file delivery, see this guide to file access control.

Pre-Flight Checks for Cross-Browser Compatibility

Test the exact client-facing URL as an external recipient, not just the local project. Use a clean browser session, a private window, a mobile viewport, and the operating systems available to the review group. The page must be evaluated as a published experience, including redirects, asset loading, protected states, and any external resources.

Test the flows clients will actually review

Don't perform a vague “looks good” pass. Define the 3 to 5 client tasks the prototype is meant to validate, then run those tasks in each target environment.

Chrome: Check the primary flow, modern CSS behavior, forms, and console errors.
Safari: Inspect WebKit-specific rendering, font metrics, sticky elements, media, and touch interaction.
Firefox: Verify layout, focus behavior, form controls, and standards-sensitive features.
Edge: Confirm that navigation, embeds, and business-managed browser settings don't alter the experience.
Mobile: Test the actual responsive breakpoints, orientation changes, tap targets, scrolling, and reduced-motion behavior.

Google's Core Web Vitals “good” experience thresholds are LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less at the 75th percentile (Google's Core Web Vitals guidance). Use those as production-style targets for a performance check, while remembering that a prototype's purpose and traffic conditions may differ from a live product.

Run a keyboard-only review

Put the mouse aside and use only Tab, Shift+Tab, Enter, Space, and Escape. Every control should be reachable, the focus order should make sense, focus should remain visible, and dialogs shouldn't trap the user. Test browser zoom up to 200%, check that focused content isn't obscured, and verify that menus, forms, errors, and overlays remain understandable.

WCAG 2.2 covers keyboard operation, no keyboard trap, focus order, visible focus, and unobscured focused content (WCAG 2.2 understanding documentation). Guidance on content migration and launch control is also useful when a prototype is part of a larger redesign handoff, where content and technical behavior need to be checked together.

Record each issue with the URL or interface state, browser, reproduction steps, expected result, and severity. This gives the client a clean review path and keeps accessibility defects from being mistaken for design disagreement.

Managing Feedback and Updating the Prototype

A live link improves delivery, but it won't produce useful feedback by itself. Clients need to know what the prototype is validating, which interactions are simulated, what isn't included, and where to leave comments. Send that context with the URL instead of expecting reviewers to infer the scope from the interface.

A compact review note can include:

Review goal: “Please assess whether the onboarding flow explains the value proposition before account creation.”
Priority tasks: Name the exact screens, actions, or content decisions to test.
Known limitations: Identify placeholder data, simulated integrations, unfinished states, and unsupported browsers.
Feedback format: Ask for the observed behavior, affected page, and suggested change rather than a general reaction.
Deadline: Set a clear date for consolidated comments so the team isn't responding to scattered notes indefinitely.

Track the prototype version in the page itself or in the delivery note. Record the date, change summary, and intended audience for each build. If the platform supports file replacement, update the underlying package at the same public address after recording the feedback and build identifier. That prevents bookmarked links from multiplying across a review cycle.

Read analytics as signals, not approval

Viewer data can show whether people reached a route, which device they used, or where they stopped. It can't tell you whether they agreed with the content. A long dwell time may indicate careful consideration, or it may mean the reviewer is confused. A short visit may reflect approval, a broken interaction, or a busy stakeholder.

Pair any available analytics with direct task-specific feedback. Ask, “Could you find the saved report?” rather than, “Did you like the dashboard?” Reviewers should be able to report the browser, device, page, state, and reproduction steps for a problem.

Accessibility belongs in this feedback loop from the first review. Recent accessibility reporting found only 1,021 of 9,750 audited sites, or 10.47%, fully accessible (accessibility reporting). That finding doesn't diagnose your prototype, but it shows why visual approval alone is a weak validation method. Keyboard access, focus, contrast, semantics, and mobile behavior affect who can review the work and how accurately they can respond.

Bridging Physical and Digital Reviews with QR Codes

A QR code is useful when the client is holding a printed handout, reviewing a concept in a meeting, or scanning a business card after an event. Point it to the short public prototype address, not to a large encoded payload. That keeps the symbol simpler and lets you replace the hosted build without reprinting the artwork, provided the public address remains unchanged.

Choose tolerance for the physical context

QR codes use Reed-Solomon error correction, so print conditions affect the appropriate level. The ISO/IEC 18004:2024 standard specifies four levels: L supports recovery of about 7% of symbol codewords, M 15%, Q 25%, and H 30% (ISO/IEC 18004:2024). Higher correction improves tolerance for dirt, wear, or a logo overlay, but it reduces how much payload fits at a given symbol size.

For a clean office handout, a moderate setting may be sufficient. For an outdoor poster, worn card, or branded code with an overlay, higher correction can be more appropriate. Keep strong contrast, preserve the quiet area around the symbol, and scan the final printed artwork with more than one phone before distribution.

Keep scan measurement separate

A QR scan and a browser click represent different channels. Label the QR destination or use the platform's documented QR workflow so physical scans can be distinguished from email and website visits. Don't infer analytics fields that the service hasn't documented, and don't treat scan volume as evidence of prototype approval.

The same principle applies to other file types. If a printed review includes a PDF alongside the HTML prototype, a guide to creating a QR code for a PDF can help you choose the appropriate destination format. The review brief should still identify the version, the intended tasks, and the feedback deadline.

LinkShip lets you publish a single HTML file or zipped static site as a browser link, with documented access controls, file replacement, analytics, and QR workflows available according to the applicable plan. Visit LinkShip to turn your next prototype handoff into a controlled review URL instead of another fragile email attachment.