The first custom cursor I ever shipped worked perfectly on my machine and did nothing at all on the client’s. No error, no warning, no fallback. The pointer just stayed an arrow. The file was a 200 by 200 pixel PNG, which my browser happened to tolerate and theirs quietly refused. That is the thing about this property: when it fails, it fails without telling anyone, and you only find out because someone mentions the cursor looks normal.
The Property Itself
A custom cursor is one CSS declaration. The complexity is entirely in the rules around it.
.custom-area {
cursor: url("cursor.png") 4 12, auto;
}Three parts. The image, the hotspot coordinates, and the fallback keyword. Miss any one and you get behaviour ranging from slightly wrong to nothing at all.
The Fallback Keyword Is Not Optional
This is the single most common reason a custom cursor does nothing. The MDN cursor reference is explicit: a keyword value must be specified, indicating either the type of cursor to use, or the fallback cursor to use if all specified icons fail to load.
So this is invalid and will be dropped entirely:
/* Invalid. No fallback keyword. The whole declaration is discarded. */
cursor: url("cursor.png");
/* Valid. */
cursor: url("cursor.png"), auto;
/* Valid, with several candidates tried in order. */
cursor: url("cursor.svg") 8 8, url("cursor.png") 8 8, pointer;Pick the fallback to match the meaning of the element rather than defaulting to auto everywhere. On a clickable card, pointer is the honest fallback, because if your image fails the user still gets the signal that the thing is clickable. Falling back to auto there loses that.
Size Limits: Why Your Cursor Is Being Ignored
This is what bit me on that first project. MDN notes that while the specification does not limit the cursor image size, user agents commonly restrict them to avoid potential misuse. Specifically, in Firefox and Chromium, cursor images are restricted to 128 by 128 pixels by default, and the documentation recommends limiting the cursor image size to 32 by 32 pixels.
The failure mode is the important part: cursor changes using images larger than the user agent maximum supported size will generally just be ignored. Not scaled down. Not warned about. Ignored.
So the practical rule is 32 by 32 for anything you actually ship, and treat 128 by 128 as the hard ceiling rather than a target. If your design calls for a large circular cursor, the CSS property is the wrong tool and you want the JavaScript approach further down.
| Size | Result |
|---|---|
| 32 by 32 | Recommended by MDN. Safe everywhere. |
| Up to 128 by 128 | Default ceiling in Firefox and Chromium. |
| Larger than the ceiling | Declaration ignored. No fallback image is tried. |
Hotspot Coordinates, the Part Everyone Skips
The two numbers after the URL are the hotspot: the exact pixel inside your image that counts as the pointer tip. MDN describes them as relative to the top left corner of the image, which corresponds to 0 0, and clamped within the boundaries of the cursor image. If the values are not specified, they may be read from the file itself, and will otherwise default to the top-left corner.
That default is why so many custom cursors feel subtly broken. If you draw a crosshair centred in a 32 by 32 image and omit the hotspot, the actual click point is the top left corner, 16 pixels up and 16 pixels left of where the crosshair appears to be pointing. Everything the user clicks lands slightly off from where they aimed.
/* Crosshair: hotspot at the centre of a 32x32 image */
.canvas { cursor: url("crosshair.png") 16 16, crosshair; }
/* Arrow: hotspot at the tip, near the top left */
.stage { cursor: url("arrow.png") 2 2, default; }
/* Magnifier: hotspot at the centre of the lens, not the handle */
.zoom { cursor: url("magnify.png") 12 12, zoom-in; }Set the hotspot deliberately every time, even when the answer is 0 0. It costs two characters and removes a whole class of complaints that get reported as the site feeling imprecise.
Also Read: CSS hover effects in Elementor covers the hover layer that usually ships alongside a custom cursor.
Which Image Formats Actually Work
Per MDN, user agents are required by the specification to support PNG files, SVG version 1.1 files in secure static mode that contain a natural size, and any other non-animated image file formats that they support for images in other properties. Desktop browsers also broadly support the .cur format.
Two details matter in practice. The SVG must contain a natural size, meaning explicit width and height attributes, not just a viewBox. An SVG sized only by viewBox is a common silent failure. And animated cursors are optional rather than required: MDN says user agents should also support SVG in secure animated mode, which means you cannot rely on it.
Ship PNG for anything that has to work. Use SVG when you control the audience and you have set an explicit size.
The JavaScript Follower Cursor
Everything above describes replacing the pointer bitmap. The large circles and blend-mode blobs on agency sites are a different technique: the real cursor is hidden, and a positioned element follows the mouse.
.cursor-dot {
position: fixed;
top: 0;
left: 0;
width: 32px;
height: 32px;
border-radius: 50%;
border: 2px solid currentColor;
pointer-events: none; /* critical: never eat clicks */
will-change: transform;
z-index: 9999;
}const dot = document.querySelector('.cursor-dot');
let x = 0, y = 0, cx = 0, cy = 0;
addEventListener('pointermove', e => { x = e.clientX; y = e.clientY; });
function loop() {
cx += (x - cx) * 0.18; // easing toward the pointer
cy += (y - cy) * 0.18;
dot.style.transform = `translate3d(${cx - 16}px, ${cy - 16}px, 0)`;
requestAnimationFrame(loop);
}
loop();Three things in that snippet are doing real work. pointer-events: none stops the follower from intercepting clicks, which is the bug that makes an entire site unusable if you forget it. Driving position with transform rather than top and left keeps the movement on the compositor instead of forcing layout on every frame. And updating inside requestAnimationFrame rather than directly in the event handler caps the work at one update per frame no matter how fast the pointer events arrive.
The cost is real. You now have an element repainting every frame for the entire session. On a page already struggling, that shows up in interaction latency. Our notes on Elementor Core Web Vitals cover where that budget goes.
Touch Devices and the Pointer Media Query
A follower cursor on a touchscreen is worse than useless. There is no pointer to follow, so the element either sits frozen in a corner or jumps to the last tap. Gate the whole thing behind a media query that asks whether a fine pointer exists.
.cursor-dot { display: none; }
@media (pointer: fine) and (hover: hover) {
.cursor-dot { display: block; }
body { cursor: none; }
}
@media (prefers-reduced-motion: reduce) {
.cursor-dot { display: none; }
body { cursor: auto; }
}Note that the default is hidden and the query turns it on, rather than the other way round. If the query fails to match for a reason you did not anticipate, the user gets a normal working cursor instead of a broken one.
There is also a platform limit worth knowing. MDN records that iPadOS supports pointer devices like trackpads and mice, that the iPad cursor is displayed as a circle by default, and that the only supported value that will change the appearance of the pointer is text. So on iPadOS your custom cursor image will not apply regardless of what you do.
Also Read: How to add GSAP animations in Elementor is the better route if you want the follower to ease, snap, and react to hover targets.
Accessibility: Never Hide the Cursor Globally
The follower pattern requires cursor: none on the body, and that is where it gets risky. The system cursor is an assistive feature for a lot of people. Users with low vision often enlarge it at the OS level, and hiding it replaces something tuned to their needs with a decorative circle that is usually thinner and lower contrast.
- Respect
prefers-reduced-motionby restoring the real cursor, as in the snippet above. A lagging follower is exactly the kind of motion that setting exists for. - Never apply
cursor: noneto form fields. Text entry depends on the caret and the I-beam. - Keep focus styles completely independent. Keyboard users never see the cursor at all, so it must never be the only affordance.
- Make the follower at least as visible as the pointer it replaced. A 1 pixel light grey ring on a white page is a downgrade.
Doing It in Elementor
For the simple case, the CSS property needs no plugin at all. Upload the image to the media library, copy its URL, and add one rule in the Custom CSS panel of the section or the widget. Scope it to a class rather than body so you can turn it off per template.
selector .interactive-zone {
cursor: url("/wp-content/uploads/2026/09/cursor.png") 16 16, pointer;
}For the follower version you need the markup, the CSS, and the script together, which is a custom HTML widget plus a bit of care about where the script runs. Keep the element outside any container that has overflow: hidden, or it will be clipped at the section boundary. The Plus Addons for Elementor is worth reaching for here mainly because the hover and interaction states are what make a follower cursor feel intentional rather than decorative, and wiring those consistently by hand across many widgets is the slow part.
Whichever route you take, define the cursor image once as a global so a redesign does not leave three different pointers scattered across templates. Building a reusable design system in Elementor V4 covers that setup.
When to Skip It Entirely
Custom cursors earn their place on portfolio sites, agency work, product launches, interactive canvases, and anywhere the visit is itself the experience. They cost you almost nothing there and they are memorable.
Skip them on checkout, forms, dashboards, documentation, and anything people use under time pressure or repeatedly. In those contexts the pointer is a tool, the user has already learned its exact behaviour, and replacing it makes the interface slower to use in exchange for a stylistic note nobody asked for.
A reasonable middle position is to scope the effect to one section. A custom cursor inside a portfolio gallery, with the normal pointer everywhere else, gets you the character without taxing the parts of the site that have work to do.
Frequently Asked Questions
Why Is My Custom Cursor Not Showing?
Three causes account for nearly all of it. The image is larger than the 128 by 128 ceiling that Firefox and Chromium apply, so the declaration is ignored. The fallback keyword is missing, so the whole declaration is invalid. Or the image path is wrong, in which case the fallback keyword is what you are seeing.
What Size Should a Custom Cursor Be?
32 by 32 pixels. MDN recommends that size explicitly, and it is comfortably under the 128 by 128 default ceiling in Firefox and Chromium. Anything larger than the ceiling is ignored rather than scaled.
Can I Use an Animated GIF as a Cursor?
Not reliably. The specification requires support for non-animated formats and only says user agents should support animated ones, so it is optional. If you need motion, use the JavaScript follower and animate a normal DOM element.
Do Custom Cursors Work on Mobile?
No, and they should be disabled there. Touchscreens have no persistent pointer. On iPadOS with a trackpad, MDN notes the cursor shows as a circle and only the text value changes its appearance, so custom images do not apply. Gate the effect behind @media (pointer: fine).
Are Custom Cursors Bad for Accessibility?
Replacing the cursor image is low risk. Hiding it with cursor: none for a JavaScript follower is higher risk, because it overrides OS-level cursor size and contrast settings that some users depend on. Honour prefers-reduced-motion, keep the system cursor on form fields, and make the replacement at least as visible.
