liquid-glass-studio: a shader laboratory for the glass effect, in the browser

A studio application, not a component you can install

The description calls it the ultimate Apple Liquid Glass UI recreated for the web, powered by WebGL2 and WebGPU, and the README expands that to a web recreation with most Liquid Glass features and fine-grained controls for detailed customization. What ships here is an application with a control panel, not a library.

The repository structure makes that concrete. There is an index.html at the root, a src/ directory, public/, and a Vite setup with vite.config.ts and three tsconfig files split for the app and the node tooling. The package.json is named liquid-glass and marked private, with version 0.0.0, which is the shape of an application that is not published to a registry rather than of a distributed package.

The project is deployed and viewable. The homepage and the online demo both point at liquid-glass-studio.vercel.app, and the README adds a second address for users in mainland China. Screenshots and a title video live in the .github/assets directory.

So the realistic users are two groups: a designer or front end engineer who wants to dial in this look quickly, and a developer who wants to read how someone implemented refraction and dispersion rather than copy an opaque effect. Both are served by the same artifact. Nobody is expected to install this as a dependency, and the MIT licence applies to the source rather than to a component API.

The effect list reads like a shader checklist

The Apple Liquid Glass features the README claims are present map almost one to one onto a rendering pass: refraction, dispersion, Fresnel reflection, superellipse shapes, a blob effect for shape merging, glare with a customizable angle, Gaussian blur masking, and anti-aliasing.

Each of those is a distinct piece of optics rather than a decoration. Refraction bends what is behind the glass. Dispersion splits the refraction by channel, which is why the edges of real glass fringe with colour. Fresnel reflection is the angle dependent component of the reflection. Superellipse gives the rounded rectangle shape that reads as an Apple system control rather than a plain rectangle. Glare is the directional highlight, and its angle being adjustable is what makes the effect feel lit by a source.

The blur masking entry is the one that needs the most explanation, and the README hints at the mechanism in its technical highlights, where multipass rendering is named as the way to get high quality and performant Gaussian blur. A single pass blur cannot sample far enough without visible artefacts, so the renderer runs several passes with progressively smaller radii.

Fine-grained control is the point of the project. The README lists real-time parameter adjustments through an intuitive UI, and background options that accept both images and videos, so what sits behind the glass can be moving. Spring-based shape animations with configurable behaviour are also supported, which is how the shapes move rather than sitting still.

SDF shapes and a smooth merge are what make blobs possible

Two implementation details explain how the shapes behave. The README names SDF defined shapes, signed distance fields, together with a smooth merge function, and credits the SDF functions and the smooth merge function to Inigo Quilez.

A signed distance field describes a shape as a mathematical function rather than as geometry, which means the shader can compute it per pixel instead of rasterising a mesh. For this project that buys several things at once. A superellipse, which is not a primitive any graphics API ships with, is trivial to evaluate as a distance function. Anti-aliasing comes from the field's gradient, so edges stay smooth at any resolution. And the distance value itself gives a natural mask for the blur, which is how the glass knows what to refract and what to leave alone.

The smooth merge is the second half. Two shapes in the same scene normally either overlap or sit apart. A smooth minimum of the two distance fields makes them flow into each other, which is the blob effect described in the feature list as shape merging. Doing that in a shader rather than in CSS means the merged region refracts correctly, because the shader is computing the glass surface itself rather than compositing a pre-rendered image.

The credits list also names a sample photo of buildings, sample videos of fish and of city traffic, and a sample photo by Apple and Tim Cook, so the default scenes are chosen to show off refraction over detailed, high frequency content.

Leva for the panel, React Spring for the motion

The control surface is built on Leva, with custom Leva UI components for intuitive parameter controls, and the package list shows leva as a runtime dependency rather than a development one, which is the usual sign that the panel ships inside the app.

That choice shapes what you can do with the project. Leva panels are generated from a parameter schema, so every knob the studio exposes is a declared value rather than a hand built input, and the values can be tweaked live while the canvas redraws. The README's technical highlights also credit custom shader implementations for the glass effects, so the pipeline is not assembled from a stock shader.

Motion comes from @react-spring/web, a spring based animation library, and the README describes spring-based shape animations with configurable behaviour. Spring rather than easing curves is the right primitive here, because the shapes need to respond to parameter changes and settle rather than jump.

Around those two, the interface is conventional React: react and react-dom at version 19.3.0, @mui/material and @mui/icons-material for components, @emotion/styled for styling, clsx for class name composition, re-resizable for draggable and resizable panels, and modern-normalize for baseline CSS. The shader side has its own tooling, with vite-plugin-glsl and prettier-plugin-glsl, which tells you GLSL sources are first class files in the project rather than strings embedded in components.

Two rendering backends and the question of which one you get

The renderer is described as dual-backend, WebGL2 and WebGPU, with a checklist item for rendering with WebGPU marked done. WebGL2 is the baseline that works broadly, WebGPU is the path with more capability, and the dependency list includes @webgpu/types to make the newer API type-safe in TypeScript.

Keeping both is a real engineering decision with a real cost. The rendering code has to satisfy two different APIs, the feature set can differ between them, and every parameter you tune may not behave identically on the two paths. The alternative of shipping WebGPU only would be simpler but would exclude browsers without it.

The build tooling supports the split cleanly. The Vite plugin @vitejs/plugin-react-swc handles React compilation, vite-tsconfig-paths resolves the path aliases in a multi-file src/, and TypeScript is pinned at approximately 5.8.3. The production build script compiles types and then bundles.

  "scripts": {
    "dev": "vite",
    "build": "tsc -b && vite build",
    "lint": "eslint .",
    "preview": "vite preview"
  },

A reader who wants to reproduce the effect should note that the WebGL2 path is the reference implementation in practice, since the WebGPU path is newer and the repository has no release notes describing where the two diverge.

Running it takes pnpm and a browser with WebGL2

The getting started section lists Node.js with the latest LTS version recommended, and pnpm as the package manager, which is consistent with the pnpm-lock.yaml and pnpm-workspace.yaml files at the root. The installation and first run is three commands.

pnpm install
pnpm dev
pnpm build

pnpm install resolves the dependency tree from the committed lock file, pnpm dev starts the Vite development server, and pnpm build produces the production bundle. The lint script runs eslint over the project, and preview serves the built output locally.

Two prerequisites are not stated as commands but matter more than they look. The first is a browser with WebGL2, since the entire effect is rendered on the GPU and the studio cannot degrade to a flat UI without it. The second is that the project is an application, so there is no API surface to import. What you take from a fork is the source under src/, the shaders and the parameter definitions, and the freedom to change the control panel.

There is also an openspec/ directory at the root, which suggests the project keeps some specification documents alongside the code, and the .github/assets folder carries the media used in the README.

The checklist says what is not finished yet

The most honest part of the README is its TODO list, and it is worth reading as a scope statement rather than as a wish list.

Done are more glare controls covering hardness, colour and size, custom backgrounds, rendering with WebGPU, control parameter import and export, and a render step view that shows intermediate results. Not done are editor mode, glass text rendering, glass presets, self-illumination, HDR illumination, and putting UI content inside the shape.

Each missing item is a real capability a production interface would want. Glass presets would let a designer pick a look rather than rebuild one parameter set at a time. Glass text rendering is the hard one, because text inside a refracting shape needs the shape to refract the text rather than a background behind it. Self-illumination and HDR illumination are lighting features the current implementation has no equivalent for. Editor mode, in a project with an openspec/ directory, suggests the author expects the studio to grow into something a designer drives directly.

The parameter import and export feature is the one that turns those TODOs into a workflow rather than a blocker: you can tune a look, export the parameters, and reuse them in your own implementation without needing the studio to be finished.

On maintenance, the repository is not archived and the last push was on 2026-09-11, but it has no GitHub releases, so there is no versioned artifact to install and the reference is the main branch. The licence is MIT, which is permissive and carries only a notice requirement when you redistribute the code.

Editorial conclusion

Adopt liquid-glass-studio as a reference implementation and a parameter playground if you are building a glass interface for the web and want to see how refraction, dispersion, glare and blur masking are wired together in one shader pipeline. Do not adopt it as a component library, because the repository ships an application and a studio, not a packaged glass component with a public API, and several listed features such as editor mode and glass text rendering remain unchecked. Verify first by running pnpm dev and switching the renderer between WebGL2 and WebGPU on the target hardware, then confirm the effect still holds when the background is a video rather than a still image.

Frequently asked questions

Official sources

1. Issues
2. iyinchao/liquid-glass-studio on GitHub
3. License: MIT
4. Project website
5. README