3dsvg: turning SVG artwork into interactive React 3D

Extruded vector paths rendered with Three.js

3dsvg turns SVG artwork into an interactive 3D object inside a React application. The mechanism is visible in the engine source layout: a scene module holding the 3D scene, an ExtrudedSVG type and the Canvas, a controls module for animations and smooth interaction, a materials module with ten PBR material presets, a types module that defines SVG3DProps and the defaults, and a font loading hook.

The rendering stack is React Three Fiber on top of Three.js, with React Three Fiber providing the declarative layer over the underlying renderer. Text input is handled separately: opentype.js converts font glyphs to vector paths, which is why the text input mode can work with ten Google Fonts rather than needing you to supply an SVG for every label.

The audience is front end developers who want a 3D accent, not a 3D artist. A logo, an icon, a badge or an illustration that already exists as a vector file becomes an interactive object with a few props, and the geometry work is done at runtime in the browser.

The editor renders the same component you embed

The repository is a monorepo with two packages under packages/. The engine package holds an embeddable SVG3D React component and is published to npm as 3dsvg. The web package is the visual editor served at 3dsvg.design, where you design 3D objects and export them as images, video, 3D models or embed code.

The line the README draws is the important one: the web editor renders the engine's SVG3D component directly, so what you see in the editor is exactly what you get with the embed. There is no second renderer, no export pipeline that approximates the preview, and no drift between design mode and shipped mode. That property is what makes an editor-based tool trustworthy, and it is the reason to believe an exported embed code snippet reproduces the editor state.

The engine is bundled with tsup and the root package.json declares npm workspaces over packages/*, so the two packages share one lock file and one dependency tree. The engine requires Node 18 or later according to the engines field, and the repository root also carries DESIGN.md, an llms.txt file and a vercel.json for deployment.

Materials, animations and lighting as props

The public API is small, which is the point of an embeddable component:

import { SVG3D } from "3dsvg";

<SVG3D text="Hello" animate="spin" />
<SVG3D svg="/logo.svg" material="gold" />

One prop chooses the source, another chooses the animation, another chooses the finish. The engine source shows the defaults live in types.ts, and the README points to the engine package documentation for the full prop list.

The catalogue behind those props is what makes the output look deliberate. Ten material presets are listed: Default, Plastic, Metal, Glass, Rubber, Chrome, Gold, Clay, Emissive and Holographic. Seven animation modes are available: Spin, Float, Pulse, Wobble, Swing, Spin+Float, or static. Textures come as ten procedural presets or as your own upload. Lighting is configurable in the key light position and intensity, ambient level and shadows.

For an interactive canvas the README lists drag rotation with momentum, scroll zoom and cursor-follow orbit, plus responsive behaviour that auto-zooms on narrow or portrait viewports so the object stays visible. The same set of controls is available in the editor, which is how you tune the values before exporting the JSX snippet.

Export paths: PNG, video, GLB, STL, OBJ and PLY

The editor is not only a preview. Its export options cover the cases a designer actually needs, and each one goes a different route.

PNG export produces a transparent or background image at up to 4K resolution. Video export records the canvas at 60fps with a trim interface in the iOS style and writes either MP4, through FFmpeg WASM, or WebM, with quality control. The MP4 path is the expensive one: the conversion runs in the browser through a WebAssembly build of FFmpeg, which is a large download compared with the rest of the tool.

3D model export is the least obvious capability and possibly the most useful for a pipeline. The scene can be downloaded as GLB, with colour and materials preserved, as STL for 3D printing, or as OBJ and PLY. A GLB with materials intact is the format that most real time viewers can consume, so the editor can act as a bridge from flat vector assets into an existing 3D workflow.

The remaining editor features support the pipeline rather than the model: a camera mode with a shutter button, an aspect ratio picker and a viewfinder overlay for framed captures, and embed code export that produces a copy ready SVG3D JSX snippet carrying every prop from the current editor state.

Running the monorepo locally

The quick start in the README is three commands from the repository root:

npm install
npm run build:engine
npm run dev:web

The build of the engine package comes first because the web app imports it, and the workspace scripts in the root package.json show how the pieces are wired: dev runs the engine and web development servers together with npm run dev:engine and npm run dev:web, each of which delegates into its workspace with npm --workspace=packages/engine or packages/web, and build runs the engine build followed by the web build.

Once the web development server is up you open http://localhost:3000 and the editor loads. Since the editor is the Next.js application in packages/web with its app/ directory for pages, components/ for the editor interface and export bar, and lib/ for textures, FFmpeg and utilities, the Next.js conventions apply to it as they would to any other Next.js project.

For use in your own project the install is the published package:

npm install 3dsvg

After that the component is imported by name and configured with props, as the embed example shows. The engine's own README holds the complete prop reference, which is the document to read before you design your own preset of materials and animations.

Where 3dsvg is the wrong tool

The geometry model is the boundary that decides most cases. Extruding a 2D path produces a solid with depth, and that is the whole shape vocabulary. A character, a machine or anything with an interior cavity is not what this pipeline produces, so a team that needs modelled 3D assets is in the wrong place.

The alternative approach is the reverse workflow: model the object in a 3D authoring tool, export it as GLB or STL, and display that file in the page. The difference in approach is where the geometry comes from and who pays for it. The traditional route gives arbitrary geometry and a real time asset pipeline, at the cost of modelling skill and asset maintenance. 3dsvg gives you geometry from artwork your designer already has, with materials and lighting applied at runtime, at the cost of the shape limitations above.

Two more practical limits. Everything happens in the browser, so the object, the shaders and the export tooling are all client side, and the FFmpeg WASM path in particular is a meaningful download for a visitor on a slow connection. And the engine is a React component, so it needs React and a bundler in your project, and any page where you would rather have a static image of a 3D object is better served by one of the export outputs instead.

There is also the usual caveat for a project without GitHub releases: there is no tagged version to pin, so you depend on whatever the npm registry currently serves.

MIT licence, a single author and no tagged releases

The licence is MIT, credited to Renato Costa, so the code can be reused in commercial and open source products under its terms.

The project is young and small in a way that is worth naming rather than glossing over. The repository has no GitHub releases, so the version history lives in commits and on npm. The last push was on 2026-05-30, which is inside the six month window, but the release record on npm is the only version reference available to consumers, and there is no migration guide or changelog in the repository entries to tell you what changed between two versions of the props API.

The stack choices suggest where the project is heading. Next.js 16 with the app router for the editor, React Three Fiber over Three.js for rendering, Tailwind CSS v4 and shadcn/ui for the interface, and a Next.js based monorepo with tsup bundling the engine separately so that the published package stays small. The root also carries a .claude/ directory and a llms.txt file, which are signs of a workflow where the repository is read by tools as much as by people.

Editorial conclusion

Adopt 3dsvg if you are building a React site that needs an animated 3D object from vector artwork and you want the browser to do the geometry, the lighting and the export, without anyone learning a modelling tool. Do not adopt it for arbitrary 3D content, since the geometry comes from extruding 2D paths, and do not adopt it if you need server side rendering of the scene, because the engine runs on the browser through Three.js and React Three Fiber. Verify three things first: the bundle cost of shipping Three.js and the engine to your users, the browser support you need for the GLB and video export paths that rely on FFmpeg WASM, and whether the npm package version matches the props you plan to use, since the repository has no GitHub releases. The licence is MIT, the engine is published as 3dsvg, and the last push was on 2026-05-30.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. renatoworks/3dsvg on GitHub