What is a honeypot field? A bot trap that humans can't see

Bots fill in forms without "looking"

When a human fills in a web form, they look at the screen, recognize the input fields, and type in the right content. But bots don't "look" at the form. A bot parses the HTML source code, mechanically detects input and textarea elements, and enters values with a program.

This habit of "not looking" is the principle behind honeypot fields. You place a dummy input field that humans can't see but that exists in the HTML. Since humans can't see this field, they don't enter anything. But because a bot detects input fields by parsing the HTML, it enters a value in the dummy field too.

On the server side, any submission with a value in the dummy field is judged to be a bot and rejected. Since the dummy field is normally empty in human submissions, legitimate submissions are very unlikely to be rejected by mistake.

How to build a honeypot field

There are several ways to make a honeypot field invisible to humans but present in the HTML.

The most common is to hide it with CSS. You apply styles to the element containing the input field, such as placing it off screen (position: absolute; left: -9999px), shrinking it to zero size (width: 0; height: 0; overflow: hidden), or hiding it visually (opacity: 0).

The design of the field name also matters. Bots detect common field names like "email," "name," and "message" and fill them in automatically. Giving the honeypot field one of these names raises the chance that a bot will fill it in. Conversely, you give the real input fields names that are hard for bots to guess.

One thing to watch: if you use display: none, some advanced bots have logic that says "don't fill in hidden elements," so they may avoid detection. Placing the field off screen or giving it zero size tends to be harder for bots to detect.

You also need to think about accessibility. If a screen reader reads out the honeypot field, users with visual impairments will be confused. Set the aria-hidden="true" attribute and tabindex="-1" to exclude the honeypot field from both screen readers and keyboard navigation.

Strengths and limits of honeypots

The biggest strength of a honeypot field is that it has zero impact on the user experience. Unlike CAPTCHA, it doesn't make users pick images, and unlike Proof of Work, it doesn't need to run a calculation. Users never even notice the honeypot field is there.

Another strength is how simple it is to build. You just add a dummy input field to the HTML, hide it with CSS, and check the dummy field's value on the server side. It has no complex algorithms or dependence on outside services, and it is lightweight.

But it has limits too. Advanced bots can parse CSS hiding styles, identify honeypot fields, and avoid filling them in. Bots that use headless browsers (Puppeteer, Playwright, and so on) render the page just like a real browser, so they can recognize hidden elements and skip filling them in.

Also, honeypots have no effect on manual harassment by humans. Humans see the form and fill it in, so they never fall for a honeypot field.

Where honeypots fit in layered defense

On its own, a honeypot field can't stop advanced bots. But as one layer of a layered defense, combined with other measures, it does its job.

For services like question boxes, a layered setup that stacks honeypot fields, Proof of Work, and rate limiting is the standard.

As the lightest defensive layer, the honeypot screens out simple bots first. Bots of the type that mechanically parse HTML and enter values in every field are removed at this layer. Many bots on the web are this simple, so a honeypot alone can remove a considerable number of bots.

Bots that get past the honeypot face the next layer, Proof of Work. They have to solve a computational puzzle for each post, which sends the cost of mass posting soaring. And even if they get past Proof of Work, rate limiting caps how often they can post at all.

Because the 3 layers each work on a different principle, a technique that gets past one layer doesn't necessarily work on the others. A bot that avoids the honeypot can't necessarily avoid Proof of Work, and a bot that solves Proof of Work fast can't necessarily avoid rate limiting. This "combination of different principles" is the essence of layered defense.

Where the name honeypot comes from

The name "honeypot" comes from cybersecurity terminology. In a security context, a honeypot means "a decoy system for deliberately luring in attackers." You set up a fake server made to look like a real one, and when attackers break into it, you can observe and record their methods and goals. The name compares it to a pot of honey that lures in insects.

A honeypot field in a form is the same idea. You place a decoy input field to lure in bots, and when a bot fills it in, it gets detected. The basic idea of trapping attackers is shared with honeypots in network security.

The concept of the honeypot was systematized from the late 1990s into the early 2000s by security researchers including Lance Spitzner. At first it was used to detect network intrusions, but later it was also applied to fighting spam on web forms. Despite its simple principle, it's a long-lived technology that has kept being used as a practical defense for more than 30 years.