Root entry
Put index.html at the expected project level and confirm that its module scripts and styles point to paths that exist in the uploaded export.
All use cases
For a WebGL export
Share a Three.js export for browser review.
A Three.js project becomes reviewable when its built browser files, models, textures, and scripts travel together. Upload an already-built static export or ZIP so a reviewer can open the scene, check the resource paths, and report what needs attention before the next deployment decision.
Review lens
The static export contract
The preview can only show the files that were exported. Keep the root entry and every browser-loaded resource in the same relative structure.
Scene assets
Open the model and inspect textures, environment maps, fonts, and other resources that the scene loads from relative URLs.
WebGL loading
Use a fresh browser to check canvas creation, script order, console-visible resource failures, and the basic scene or interaction the export is meant to demonstrate.
A real moment for the page
A browser link makes the next conversation concrete.
Model and scene review
Give a client, art director, or teammate a link to inspect the camera, lighting, models, materials, textures, and intended presentation.
Export smoke check
Reload the published files in a fresh browser and catch missing modules, incorrect asset paths, blank canvases, or export packaging mistakes.
Pre-deployment handoff
Share the built artifact with a focused review question before moving it into the team’s production host, app shell, or release workflow.
Why this handoff works
Keep the useful part close to the artifact.
Review the files that shipped from the build
The browser link represents the static export rather than a source folder that still needs npm install, a dev server, or a local build command.
Keep 3D resources together
A complete ZIP makes models, textures, scripts, styles, and the root entry easier to verify as one reviewable artifact.
Separate visual confidence from runtime confidence
Use the preview to inspect the exported scene while keeping performance, hardware, server, and production deployment checks in their proper environments.
A three-step workflow
From the right files to the right reaction.
- 01
Build or export elsewhere
Run the Three.js bundler or export workflow in your normal local or CI environment. HTMLShare accepts the browser-ready result; it does not run the project build.
- 02
Package dist and assets
Zip the generated output with index.html, JavaScript bundles, models, textures, styles, and other resources at the relative paths the scene references.
- 03
Open and review the scene
Upload the export, check WebGL loading and asset paths in a fresh browser, then share the link with the reviewer and the specific question to answer.
Know the boundary
A preview is useful because it is honest.
HTMLShare publishes browser-ready static output. Keep builds, source tools, private access, live data, and production operations in the systems built for them.
No npm build service
HTMLShare does not install dependencies, run npm scripts, bundle source modules, or turn an unbuilt Three.js repository into a deployable export.
No backend or WebXR runtime
The workflow publishes static browser files. Backend APIs, server state, authentication, WebXR services, and other runtime integrations need their own environment.
Not a performance guarantee
A scene loading in one browser does not prove frame rate, device compatibility, memory behavior, or production performance. Test those claims with the hardware and deployment target that matter.
Keep exploring
The next useful page is nearby.
Before you publish
Three.js static export review FAQ
Can HTMLShare build my Three.js project?
No. Build or export the project in your normal local or CI workflow first, then upload the already-built static output or a ZIP containing the complete browser files.
What should a Three.js export ZIP include?
Include index.html at the expected root level plus the JavaScript bundles, models, textures, styles, fonts, and other static resources referenced by the scene with their relative paths.
Will a Three.js backend or WebXR feature work in the preview?
Not as a hosted runtime. The workflow serves static browser files and does not provide backend APIs, server state, authentication, WebXR services, or other application infrastructure.
Does a working preview guarantee Three.js performance?
No. The preview helps inspect loading and visible behavior. Measure frame rate, memory, hardware compatibility, and production performance in the target environment.
Ready for the next review
Put the current page in front of the right person.
Create a noindex preview link for the static HTML or ZIP project, then move approved work to production when it is ready.