The Blank Gap Above Your Gravity Forms Button Is Turnstile

The short answer

The blank band is the Turnstile field holding space for its challenge. Most visitors pass without seeing anything, so the space looks empty. When Cloudflare is not sure about a visitor, a “Verify you are human” box appears right there. If you collapse the space, those visitors cannot send the form, and nothing tells you it happened. Leave the space alone and move the button into it.

What you are seeing

With Gravity Forms’ official Turnstile add-on, the check is added to the form as a field. On a normal visit the widget passes quietly in the background, but the field still keeps its space, about the height of the challenge box. The submit button sits under an empty band. On my own contact form it was about 74 pixels tall, and it looked exactly like a layout bug.

To confirm it, inspect the empty band with your browser’s developer tools. You will find a field with the class gfield--type-turnstile, and inside it a div with the class cf-turnstile. That div is where Cloudflare draws the challenge.

I only understood what it was for when I loaded the form in a headless browser. Automated browsers get the challenge almost every time, and there it was, filling the band.

Why you should not hide it

The obvious fixes all break the form for somebody:

• Hiding the field with display: none hides the challenge the moment Cloudflare decides to show one.
• Collapsing it with height: 0 or overflow: hidden does the same thing, more quietly.
• Pulling the button up over the band with a negative margin can cover the challenge box.

Every one of those fails silently. The challenge is there, the visitor cannot see it, the form will not send, and they leave. You never hear about the inquiry you lost. A blank band costs nothing. A form that cannot submit costs leads.

The fix: put the button in the band

On wider layouts, place the submit button at the right-hand end of the band, beside the challenge box. The challenge box is about 300 pixels wide and sits at the left, so the button never covers it. On phones, leave the normal stacked layout. This is the CSS, scoped to forms that actually contain a Turnstile field:

@media (min-width: 600px) {
  .gform_wrapper form:has(.gfield--type-turnstile) {
    position: relative;
  }
  .gform_wrapper form:has(.gfield--type-turnstile) .gform_footer,
  .gform_wrapper form:has(.gfield--type-turnstile) .gform-footer {
    position: absolute;
    right: 0;
    bottom: 0;
    margin: 0;
    padding: 0;
  }
}

Add it in Appearance, Customize, Additional CSS, or in your child theme. A few notes from putting it live:

• The :has() selector means forms without Turnstile are not touched.
• Gravity Forms has used both .gform_footer and .gform-footer, so the rule targets both.
• The button is placed against the bottom of the form, so the Turnstile field needs to be the last field. It is by default.
• Check that the form is wide enough for the challenge box and the button side by side. If it is not at 600 pixels, raise the breakpoint.
• If your theme adds extra margin to the Turnstile field, remove it, or the button will sit lower than the challenge box.

The button only moves visually. It stays after the challenge in the page order, so keyboard and screen reader users still meet them in the right order.

What about phones?

Below 600 pixels the rule does nothing, and the button stays under the band. On a phone the form is a single column anyway, so the space between the last field and the button reads as ordinary spacing rather than a gap. If it still bothers you, trim the margin around the Turnstile field a little, but keep the field’s own height. The challenge box needs it the moment it appears.

Testing a form that has Turnstile on it

Turnstile also changes how you test. Automated browsers are exactly what it is built to stop, so a test sent from a script or a testing tool will usually be challenged, or refused with an error saying the Turnstile response is invalid. That is the protection working. Do not try to get around it. Test in two parts instead.

First, test the notifications on the server. The Gravity Forms API can add an entry and send its notifications without going through the form, so you can check the emails, the routing and any integrations:

// 5 is your form ID; '1' is a field ID from that form
$form     = GFAPI::get_form( 5 );
$entry_id = GFAPI::add_entry( array(
    'form_id' => 5,
    '1'       => 'TEST entry, please ignore',
) );
GFAPI::send_notifications( $form, GFAPI::get_entry( $entry_id ) );

Label every test entry clearly, so it never ends up counted as a lead.

Second, send one real test from your own phone, logged out of WordPress. That proves the part a script cannot: a real visitor, a real Turnstile check and a real submission.

When a form looks fine and still fails

A form that quietly stops working is one of the most common problems I am called about, and it is rarely one thing. It can be a hidden challenge like this one, emails that never leave the server, or emails that arrive with broken images, like the problem in email logo not showing? Check your firewall. If yours is misbehaving and you cannot see why, WordPress repair is where I start. And if spam is the reason you added Turnstile, here is how to stop contact form spam without puzzles.

Frequently asked questions

Is the empty space a Gravity Forms bug?

No. It is the space the Turnstile field keeps for its challenge box. It looks empty because most visitors pass without seeing anything.

Can I make Turnstile take up no space at all?

You can change how the widget appears in your Cloudflare settings, but the form should still leave room for a challenge in case one is shown. Hiding that room is how forms fail silently.

Why does my automated test fail with a Turnstile error?

Because automated browsers are what Turnstile is designed to stop. Test the notifications on the server and send one real test from your phone.

Does the same idea apply to reCAPTCHA?

Yes. Never hide the space a challenge needs. The field’s class name is different, so the CSS would need to target that field instead.

Will moving the button hurt accessibility?

No. Only its position on screen changes. It still comes after the challenge in the page order, so keyboard and screen reader users meet them in the right order.