I pulled this out of imgi.co, the before/after tool I run, because the slider was never the hard part and there's no reason to keep it locked away. Take it, ship it.

The idea

Stack two images in a container. The bottom one, the "before", is just a plain img. The top one, the "after", sits inside a wrapper you clip with clip-path. Move the clip and you reveal more or less of the top image. A handle rides along the clip edge so people know there's something to drag.

The one line that does the actual work:

frame.style.clipPath = `inset(0 ${100 - pct}% 0 0)`;

pct is the handle position, 0 to 100. At 50 you clip half off the right of the top image, so the left shows the after and the right shows the before underneath. clip-path runs on the compositor and doesn't trigger layout, so dragging stays smooth even on a chunky 4000px screenshot. Animating width instead would reflow on every frame and you'd feel it.

One thing that trips people up: clip the wrapper, not the image. Resize the img itself and the picture squashes, the two frames drift out of alignment, and the whole comparison lies to you. Keep the after-image full size inside a wrapper that matches the base image, and clip the wrapper.

Dragging, for real fingers and mice

Skip the separate mouse and touch handlers. Pointer events give you one code path for mouse, touch, and pen:

el.addEventListener("pointerdown", (e) => {
  el.setPointerCapture(e.pointerId);
  move(e);
  window.addEventListener("pointermove", move);
  window.addEventListener("pointerup", up, { once: true });
});

function move(e) {
  const r = el.getBoundingClientRect();
  set(((e.clientX - r.left) / r.width) * 100);
}
function up() {
  window.removeEventListener("pointermove", move);
}

Two details that are easy to miss. Capture the pointer (or bind pointermove to window, like above) so a fast drag that shoots off the element doesn't just stop dead. And put touch-action: none on the handle, otherwise dragging sideways on a phone scrolls the page instead of moving the slider. Leave the rest of the element scrollable so the page still behaves.

The keyboard, which everyone forgets

handle.setAttribute("role", "slider");
handle.setAttribute("tabindex", "0");
handle.setAttribute("aria-valuenow", "50");

handle.addEventListener("keydown", (e) => {
  const step = e.shiftKey ? 10 : 2;
  if (e.key === "ArrowLeft" || e.key === "ArrowUp") set(pos - step);
  if (e.key === "ArrowRight" || e.key === "ArrowDown") set(pos + step);
  if (e.key === "Home") set(0);
  if (e.key === "End") set(100);
});

Making the handle a real focusable slider with arrow keys is maybe five lines, and it's the gap between a demo and something you'd actually put in front of users. Update aria-valuenow when the position changes so a screen reader can follow along.

Wrapping it as a custom element

Put it in a custom element and the markup on the page reads like plain HTML:

<before-after
  before="original.jpg"
  after="edited.jpg"
  before-label="Before"
  after-label="After"></before-after>

Inside, a shadow root holds the two images, the clip wrapper, and the handle, plus a bit of scoped CSS. The element reads its before and after attributes, wires up the pointer and key handlers in connectedCallback, and exposes a value property and a change event so the rest of your app can drive it or react to it. That's the entire surface.

That's the whole thing

A working before/after image comparison slider, vanilla JS, no build step, MIT. The clip trick is the core, pointer events handle the input, and a focusable handle keeps it accessible. Everything past that is taste.

If you'd rather not host it, imgi.co gives you the same slider on a permanent shareable link with a copy-paste embed, plus GIF and MP4 export for the spots a live slider won't load, like Reddit or a Discord post. But if you just want the widget on your own page, the code up there is all of it. Go build.