Center This Div is a CSS centering game with a 0.0001px success threshold
The anti-cheat system returns HTTP 418 (I'm a Teapot) for suspicious submissions
Reddit found the original 0.3px threshold too aggressive within hours of launch
Building it with Next.js 16 and Neon Postgres kept the stack dead simple
Free products generate more attention than paid launches ever could
The 418 status code turned a bug report into a feature that players actually love
The Game That Nobody Can Win
Two days ago I launched a CSS centering game called Center This Div. The premise is simple. You get a div. You need to center it. Your score is measured in pixels of offset from perfect center. The closer to zero, the better.
The catch is that perfect center means 0.0001 pixels of tolerance. Not 1 pixel. Not 0.1 pixels. Zero point zero zero zero one pixels. To put that in perspective, a human hair is about 70,000 nanometers wide. The tolerance in this game is roughly 0.1 nanometers on a standard display. You are trying to hit a target that is physically smaller than what your screen can render.
Nobody was supposed to beat it. That was the point. It launched on April Fools as part of the DEV community's #418challenge, where developers build projects around the HTTP 418 "I'm a Teapot" status code. The game was meant to be a joke. Then people actually started playing it seriously, and everything got interesting.
How the Scoring Actually Works
The game presents you with a container and a target div. You use CSS properties to position the div. The game calculates the exact pixel offset between your div's center point and the container's center point using getBoundingClientRect(). That offset becomes your score.
The calculation is straightforward:
const container = containerRef.getBoundingClientRect();
const target = targetRef.getBoundingClientRect();
const containerCenter = {
x: container.left + container.width / 2,
y: container.top + container.height / 2
};
const targetCenter = {
x: target.left + target.width / 2,
y: target.top + target.height / 2
};
const offset = Math.sqrt(
Math.pow(containerCenter.x - targetCenter.x, 2) +
Math.pow(containerCenter.y - targetCenter.y, 2)
);
Euclidean distance. Simple math. The devil is in the threshold.
At 0.0001 pixels, you are operating below the precision that most browsers actually report. getBoundingClientRect() returns values as doubles, so the precision exists in the number format. But the actual rendering engine snaps to sub-pixel boundaries that are orders of magnitude coarser than 0.0001 pixels. You can write CSS that is mathematically perfect, and the browser will still report a tiny offset because of how it rounds during layout.
This is what makes the game genuinely impossible in practice. Not because the CSS is hard. Centering a div is literally the most discussed topic in web development. But because the measurement precision exceeds what the rendering pipeline can deliver.
The Anti-Cheat That Became a Feature
Here is where the 418 status code enters the story. I needed a way to handle submissions where the offset was suspiciously perfect. If someone submits a score of exactly 0.000000 pixels, they almost certainly manipulated the DOM or spoofed the API request. The browser cannot produce that level of precision through legitimate CSS.
So the server returns HTTP 418. I'm a Teapot.
if (offset < 0.0001) {
return new Response(
JSON.stringify({ teapot: true }),
{ status: 418 }
);
}
The frontend catches the 418 and shows a custom teapot result screen instead of a score. No score gets recorded. No leaderboard entry. Just a teapot and a message suggesting the player's CSS might be a little too perfect.
What I did not expect is that players would deliberately try to trigger the teapot. Getting a 418 became its own achievement. People started competing to hit the anti-cheat threshold instead of competing for the lowest score. The teapot screen became more sought after than the actual leaderboard.
This is the kind of thing you cannot plan for. The anti-cheat mechanism, designed to prevent gaming the system, became a game within the game.
The Reddit Incident
Within six hours of launch, a post appeared on Reddit pointing out that the original threshold was set at 0.3 pixels per axis. Players who were genuinely close to center, using legitimate CSS techniques like margin: auto with precise viewport calculations, were hitting the anti-cheat and getting blocked.
The feedback was immediate and specific. People posted their CSS solutions that should have scored under 1 pixel but were being flagged as cheats. The 0.3 pixel threshold was too aggressive for the measurement precision that browsers actually deliver.
I pushed a fix within an hour. The threshold dropped from 0.3 pixels per axis to 0.0001 pixels on the Euclidean distance. This change did two things. First, it stopped false positives from legitimate CSS solutions. Second, it made the anti-cheat virtually impossible to trigger accidentally. You would need to submit a score that is literally below the rendering engine's precision floor, which only happens through DOM manipulation or API spoofing.
The fix also exposed something I should have tested more carefully before launch. The difference between "mathematically correct CSS" and "browser-reported position" is larger than I assumed. Browsers introduce sub-pixel rounding at multiple stages: during layout, during paint, and during the getBoundingClientRect() call itself. A CSS solution that is algebraically perfect can report an offset of 0.05 to 0.15 pixels purely from rendering pipeline rounding.
Lesson learned. Always test your thresholds against the actual precision of the measurement system, not the theoretical precision of the value format.
The Technical Stack
I built Center This Div with Next.js 16, React 19, and Neon Postgres. The simplicity of the stack was deliberate.
Next.js 16 handles routing, server-side rendering, and API routes. The game page is a single route with client-side game logic. The leaderboard is server-rendered with ISR for fast loads without stale data.
React 19 powers the game interface. The centering playground uses refs for DOM measurement, state for tracking the player's CSS input, and effects for real-time offset calculation as the player adjusts their solution.
Neon Postgres stores scores and player submissions. I chose Neon because the serverless Postgres model fits perfectly. The game has spiky traffic patterns, lots of requests during viral moments and very little in between. Neon scales to zero when idle and handles bursts without configuration.
The entire codebase is under 2,000 lines of application code. No state management library. No CSS framework. No component library. Pure CSS for the game interface, because using a CSS framework in a game about CSS would be ironic in the wrong way.
Deployment is on Vercel. The project went from git init to production in under four hours, including the leaderboard, the anti-cheat system, and the 418 teapot screen. Having a clear stack with minimal dependencies makes speed possible.
Why Free Products Beat Paid Launches
Center This Div is free. No paywall, no premium tier, no "upgrade to see your detailed score breakdown." The source code is public on GitHub under MIT license. Anyone can fork it, modify it, or run their own instance.
This was not charity. It was strategy.
In the two days since launch, Center This Div has generated more traffic to my shop than my last three paid product launches combined. The game page links to my studio. The leaderboard shows my brand. Every social share, every Reddit post, every Dev.to article is organic distribution that I did not pay for.
The math on free products is counterintuitive but consistent. A paid product with a 50 EUR price tag might convert 2% of visitors. A free product converts 100% of visitors into users, and a percentage of those users explore what else you offer. If the free product is good enough to generate word-of-mouth, the distribution compounds in a way that paid acquisition cannot match.
My paid products, Blueprint, the statusline builder, the various digital tools, all benefit from the traffic that Center This Div drives. The game does not make money directly. It makes everything else more visible.
This is the jab-jab-jab-right-hook pattern applied to products instead of content. Give value freely, build trust and attention, then present something worth paying for. The free product is the jab. The paid catalog is the hook.
What the Leaderboard Reveals About CSS
The leaderboard data is fascinating. After 48 hours of submissions, patterns are emerging.
The most common approach is margin: auto combined with display: flex or display: grid on the parent. This gets players within 0.1 to 0.5 pixels of center, which is excellent but not enough to top the leaderboard.
The competitive approaches use position: absolute with top: 50%; left: 50%; transform: translate(-50%, -50%). This technique produces more consistent sub-pixel centering across browsers because the transform is applied after layout, giving the rendering engine one more opportunity to round toward center.
The creative approaches use CSS custom properties with calc() to derive exact center positions from viewport dimensions. Some players are using clamp() and container queries to adapt their centering to the exact pixel dimensions of the game container. These solutions are over-engineered for the problem but demonstrate impressive CSS knowledge.
The troll approaches are my favorites. One player submitted CSS that centers the div perfectly but also rotates it 0.01 degrees. Technically centered, technically rotated. Another player used writing-mode: vertical-rl to center horizontally but in a vertical writing context. Chaotic but creative.
The game is accidentally serving as a CSS knowledge test. The leaderboard is a ranked index of centering techniques, sorted by actual browser-measured precision. I am considering publishing an analysis of the top 100 submissions as a standalone resource on CSS centering methods.
Open Source as Product Strategy
Making the game open source was another deliberate decision. The MIT license means anyone can use, modify, and distribute the code. Here is why that helps rather than hurts.
Community contributions improve the product. Within 24 hours of the repo going public, I received pull requests for accessibility improvements, mobile layout fixes, and a dark mode toggle. These are improvements I would have eventually made myself, but the community delivered them faster.
Forks extend reach. Someone already forked the repo to create a "Center This Span" variant with inline elements. Another fork adds a time pressure mode. Each fork credits the original project and drives traffic back.
Open source builds credibility. When potential customers evaluate my paid products, seeing a well-built open source project demonstrates capability. The code quality, architecture decisions, and development practices visible in the repo are a portfolio piece that sells better than any marketing copy.
Stars and forks are social proof. The repo has accumulated stars at a rate that tells GitHub's algorithm this project is worth surfacing. That creates a discovery loop. More visibility leads to more stars leads to more visibility.
Lessons for the Next Build
Building and launching Center This Div in under a week taught me things I am applying to every future project.
Ship the simplest version first. The initial launch had five features: the game, the score calculation, the leaderboard, the 418 teapot, and social sharing. No user accounts. No history. No achievements. Those can come later if the core concept proves it has legs.
Let the community find the bugs. I could have tested the 0.3px threshold more carefully in isolation. Or I could launch and let thousands of real players hit it with approaches I never would have considered. The Reddit incident was uncomfortable but produced a better threshold in an hour than I would have found in a week of solo testing.
Free plus open source is a marketing machine. The combination of free access and open source creates two independent distribution channels: word-of-mouth from users and discovery from developers. Both run on autopilot once the product is good enough.
HTTP status codes are an untapped creative space. The 418 teapot response turned a standard anti-cheat mechanism into the most talked-about feature of the game. Status codes communicate through a channel that developers instinctively understand and appreciate. Using them creatively creates moments of delight that generic error messages never can.
If you want to try Center This Div yourself, it is live at center-this-div.vercel.app. The source code is on GitHub. And if you manage to trigger the teapot, screenshot it. That is the real achievement.
Top comments (0)