Why the background turns black
A black screenshot usually means the renderer, canvas, and page are not making the same promise. The renderer may have been created without alpha support. The scene may be clearing to an opaque color. The page may have a dark CSS background behind a transparent canvas. Or the export may happen before the frame you expect has actually been drawn.
Start by deciding what the page should own and what the renderer should own. If the WebGL scene is a product object floating above an HTML layout, let CSS own the page background and let the renderer output transparency. If the scene is a full-screen artwork, make the renderer background deliberate instead of relying on browser defaults.
Alpha is a renderer choice
The `alpha` option belongs in the WebGLRenderer constructor. Adding transparent CSS later does not retroactively give the WebGL context an alpha channel. Create the renderer with `alpha: true`, then use `renderer.setClearColor(0x000000, 0)` or keep the scene background null so the page can show through.
This matters for landing pages because designers often want text, HTML controls, gradients, and a Three.js object to share one composition. When the canvas is truly transparent, the DOM and WebGL layers can be art-directed together without awkward rectangular edges.
Screenshot export has a cost
For ordinary animation, `preserveDrawingBuffer` is usually unnecessary. For screenshot export, it can make canvas reads more reliable because the previous frame remains available for `toDataURL` or `toBlob`. That reliability has a performance cost, so use it intentionally on pages where export is a real feature.
A stronger pattern is to render one clean frame immediately before export. Update controls, resize the renderer, render the scene, then call `canvas.toBlob`. This reduces timing bugs and makes the exported image match the visible state. If the screenshot needs a transparent background, avoid CSS-only overlays in the capture because canvas export cannot include DOM text or buttons.
When to export with DOM included
Canvas export only captures WebGL pixels. If the final image must include labels, HTML annotations, or a UI frame, you need a different capture pipeline. For many small tools, it is better to export the 3D canvas alone and provide a clear note that DOM overlays are not included.
That limitation can be a feature. A clean transparent PNG of a product model, icon object, or shader preview is easier to reuse in slides, social posts, and design mockups than a screenshot polluted with interface controls.
When this guide is the right tool
Use this guide when the problem is specific enough that a broad Three.js tutorial would waste time. The focus here is screenshots in a real browser page: what to check first, what to measure, and what to avoid before the scene becomes harder to reason about.
The practical rule is simple: Create the renderer with alpha enabled before the first render. If that sentence describes the scene in front of you, treat the article as a checklist. Read the explanation, copy the smallest useful code pattern, then test the result in a narrow mobile viewport and a wide desktop viewport before adding more polish.
Common mistake to avoid
The common mistake is treating Three.js transparent background and screenshot export as a visual tweak instead of a scene-system decision. Three.js problems often look like one broken line of code, but the actual issue is usually a chain: asset assumptions, renderer settings, camera math, material setup, interaction state, and page layout all meet inside the canvas.
That is why the safest fix is incremental. Start from a known-good scene, change one variable, and keep a visible diagnostic while testing. Use preserveDrawingBuffer only when you need reliable canvas export. When the scene works, remove temporary helpers and leave behind only the checks that make sense for users.
Publishing check
Before publishing, run the scene through three questions. Does the page remain useful if WebGL fails or the asset loads slowly? Does the same scene still read clearly on a phone? Can another developer understand the important settings without reverse-engineering the whole file?
The last pass should be boring on purpose: verify canvas size, console errors, mobile performance, source links, internal links, and the related guide path. Render once immediately before calling toDataURL or toBlob. If any answer is fuzzy, fix that before introducing a new effect or a larger asset.
Transparent renderer and PNG export
const renderer = new THREE.WebGLRenderer({
canvas,
antialias: true,
alpha: true,
preserveDrawingBuffer: true
});
renderer.setClearColor(0x000000, 0);
scene.background = null;
function exportPng() {
renderer.render(scene, camera);
canvas.toBlob((blob) => {
const url = URL.createObjectURL(blob);
const link = document.createElement('a');
link.href = url;
link.download = 'threejs-scene.png';
link.click();
URL.revokeObjectURL(url);
}, 'image/png');
}FAQ
When should I use Three.js transparent background and screenshot export?
Use it when your Three.js scene has a focused screenshots problem and you need a practical checklist before adding more visual polish.
Is the code snippet production-ready?
Treat the snippet as a clear starting point. Test it in your scene, adapt naming and paths, and verify behavior on mobile hardware before publishing.
What should I check after applying this guide?
Run the scene through mobile sizing, console errors, loading states, source links, and related guide paths so the page remains useful even when assets or WebGL fail.