Liquid Morph Hover Effect

1. Add to your HTML <head>:

In your downloadThe working code for this step, in index.html.

No head probe is needed. At rest the effect draws nothing: your <img> is what shows, and the canvas only takes over an image while it is melting, on exactly the same pixels.

2. Add the markup anywhere in your <body>:

In your downloadThe working code for this step, in index.html.

3. Add before the closing </body> tag:

In your downloadThe working code for this step, in index.html.

If the module fails to load, the photographs simply stay as they are.

Why the import map rather than a plain <script src> for three.js: three ships as ES modules only, and its old UMD build logs a deprecation warning on every page load. The shim above imports it as a module (dynamically, so a blocked CDN leaves your images untouched instead of breaking the page), puts it on window, and then loads assets/script.js as an ordinary script, so the effect itself stays a plain file you can drop into any build (or none).

Already using three.js as a module? Then skip the shim, and just make sure window.THREE is set before assets/script.js runs:

In your downloadThe working code for this step, in script.js.

The melt is made of the photograph, so what is in it decides how good it looks. The shader drags colour downward and sideways, stretches the bottom rows into drips and lights the result as a wet surface. So:

• Hard edges and flat colour fields melt best. A facade against sky, a figure in a strong colour, flowers against a plain wall: you can see the edge bend, smear and run. A soft, low-contrast or busy-textured image has nothing for the eye to follow, and the melt reads as blur.
• Mind the bottom edge. The drips are the bottom rows of the image pulled long, so a bottom edge with some colour in it makes richer drips than a flat white floor.
• Any aspect ratio works. The shader cover-fits each image exactly like object-fit: cover, so the canvas lands on the same pixels as your <img>.

Judge an image fully melted (hover it and hold), not at rest.

What the effect needs from your markup: an element with the class .liquid-morph that contains one <img>. The element is the frame: its size and its corner radius are what the liquid starts from and returns to. Each .liquid-morph is independent, and you can have as many as you like on a page; they all share one canvas and one WebGL context.

What is only the demo's styling: the toolbar, the three-column gallery, the captions, the font and the colours. Delete any of it. The melt-all button is optional; any element with data-liquid-trigger-all works.

CSS the effect depends on:

• .liquid-morph.is-melting .liquid-morph__image { opacity: 0 }. While an element is liquid the canvas draws it, so the script adds .is-melting and the <img> steps aside for that time. The swap happens in the same frame the canvas starts and stops drawing, so it is invisible. Keep this rule.
• .liquid-morph-canvas is position: fixed over the viewport with pointer-events: none and a z-index. The liquid is drawn there so drips can run past the frame, over whatever sits below it. Raise or lower the z-index to put it above or below your own fixed headers.
• The <img> fills the frame with object-fit: cover. The shader matches that fit; contain or a fixed position would not line up at rest.
• Leave some room below each image if you want the drips to run onto the page; they extend up to about 40% of the image height.

Set on each .liquid-morph element.

On any element on the page:

All the images on a page share one canvas fixed over the viewport and one WebGL context. While an image is melting, the script draws it on that canvas at the image's position, with room below for the drips; at rest nothing is drawn and your <img> shows.

The shader works out, for each pixel, which part of the photograph has flowed there: a sag under gravity that grows towards the bottom and runs into drips, a slow sideways flow, and a melt front that spreads out from where the pointer came in. The colour is averaged along the path it travelled, which pulls streaks through it, and the surface is lit as a glossy liquid with a rounded edge. At zero melt every one of those terms is zero, so the last frame of a reform is the untouched photograph.

GSAP plays the melt and the reform (the progress tweens, the elastic settle and the stagger of the melt-all control), runs the frame loop on its ticker only while something is liquid, and owns the matchMedia branches, the optional ScrollTrigger modes and teardown.

• Reduced motion: nothing starts. Every photograph stays exactly as it is, and the melt-all control stays hidden.
• Without JavaScript, or without WebGL: the same: the plain photographs. One fallback for every failure mode, and it is never hidden until the canvas is actually drawing in its place.
• Keyboard: the melt-all control is a native <button> with aria-pressed. A .liquid-morph that wraps a link or button melts while that link has focus.
• Screen readers: the canvas is aria-hidden; the <img> and its alt stay in the document throughout.
• Touch: a tap melts the image and lets it reform; page scrolling is never blocked.

Anything with WebGL, which is every current browser. Support is probed before three.js is asked for a renderer: three logs its own failure to the console as errors before it throws, so catching the exception would hide nothing. Probed first, a visitor without WebGL simply gets the photographs and a clean console. Import maps are supported everywhere current; in a browser old enough to lack them window.THREE is never set and the photographs are again what shows.

One draw call per melting image, on one shared canvas; idle images cost nothing, and the loop stops completely once everything has set. Each image is uploaded to the GPU once when the page loads, not on the first hover. Images scrolled off screen are skipped, and data-trigger="auto" pauses while off screen. Pixel ratio is capped at 2 (1.5 on touch devices).

To buy back frames on low-end hardware, lower the pixel ratio cap in createStage() first: the cost is per pixel of liquid, and the smear takes six texture reads per pixel.

The three photographs ship bundled in assets/img/ as 800×1000 WebP derivatives (about 140 KB together), so the demo works offline and never hotlinks. They were chosen for the melt: a tiled facade against sky, a figure in yellow against sky and blue flowers against a pale wall, all hard edges and flat colour that show the smear, the drips and the reform clearly.

Replace a file in assets/img/ with your own, or point the src in index.html anywhere: the effect only needs an <img> inside .liquid-morph. No colour grade is baked in; the shader does the lighting. assets/img-manifest.json records the source of each image for provenance; the build script that reads it is part of the GSAP Vault repository and is not in your download.

Credits

Placeholder photographs from Pexels (photos 5504428 and 8746996, Pexels License) and Unsplash (photo 1515886657613-9f3515b0c78f, Unsplash License), used as cropped and re-encoded derivatives. Replace them with your own imagery before launch.

Everything the effect uses from three.js (WebGLRenderer, ShaderMaterial, PlaneGeometry, Texture) is long-stable API, so pinning a different version is a one-line change in the import map.