---
title: "The Input Bar: Most Important 48 Pixels in the App"
description: "Text field, voice button, send button, keyboard avoidance, safe area handling — the input bar is where every conversation begins, and its 48-pixel height must be flawless."
canonical: https://nowah.xyz/blog/input-bar-most-important-48-pixels
lastModified: "2026-08-07T08:01:52.904Z"
---

# The Input Bar: Most Important 48 Pixels in the App

Text field, voice button, send button, keyboard avoidance, safe area handling — the input bar is where every conversation begins, and its 48-pixel height must be flawless.

Every journey that starts in Nowah begins in the same place: a 48-pixel-tall strip at the bottom of the screen. A text field. A microphone button. A send button. This is the input bar, and it is the [most important](/blog/why-speed-is-most-important-feature) component in the entire app.

The input bar is the gateway to every conversation, every search, every booking. If it is uncomfortable to type in, awkward to reach, or confusing to interact with, the product fails before the AI ever has a chance to demonstrate its value. Forty-eight pixels of height. Flawless or nothing.

## Text field sizing

![Illustration for this section](https://pics.nowah.xyz/website-media/design-027-img-1.webp)

The text field must handle two extremes: a single line of text ("flights to Tokyo") and multiple lines of text ("I need a flight from JFK to NRT on April 5th, returning April 12th, two passengers, and I prefer a morning departure on the outbound and an evening return"). The first is one line. The second is four.

We use an expanding text field that starts at a single line and grows vertically as the user types more content. The expansion is smooth — the field height increases line by line, pushing the chat messages above it upward. A maximum height (approximately four lines) prevents the input field from consuming the entire screen. Beyond the maximum, the text scrolls within the field.

The expansion animation is fast (under 100 milliseconds) so the user never sees a janky resize. The chat messages shift upward with the same timing, maintaining the visual connection between the conversation and the input.

## Voice button placement

The microphone button sits to the right of the text field, inside the input bar. Its placement is fixed — it does not move as the text field expands, ensuring the user always knows where to find it.

When the text field is empty, the microphone button is the rightmost element, in the position that the send button will occupy once text is entered. This dual-use of the rightmost position creates a clear either/or: the primary action is either "start recording" (when the field is empty) or "send message" (when the field has text).

Some implementations place the microphone button to the left of the text field or above it. We experimented with these positions and found that right-side placement produces the highest voice adoption rate. The right side is where the thumb naturally rests when holding the phone in the right hand, and it is the conventional position for the primary action in chat input bars.

## Send button states

![Supporting diagram](https://pics.nowah.xyz/website-media/design-027-img-2.webp)

The send button has three clear states that communicate what will happen when tapped.

Disabled state: the text field is empty. The send button appears in a muted color, indicating that tapping it will not do anything. This prevents accidental empty message sends and communicates that the system is waiting for input.

Ready state: the text field contains text. The send button transitions to the accent green, signaling that it is active and that tapping it will send the message. The color change is the only difference needed — the transition from muted to green is unmistakable.

Recording state: voice recording is active. The send button transforms into a stop-and-send button, allowing the user to end the recording and submit the audio in a single tap. The button remains green, maintaining the "this is the primary action" signal.

These three states cover every interaction mode. The user always knows what the rightmost button will do.

## Keyboard avoidance

When the keyboard appears, the input bar must sit directly above it. Not partially behind it. Not separated from it by a gap. Directly above, with no dead space.

This sounds trivial. It is not. Mobile keyboards vary in height across devices and input modes (standard text, numeric, emoji, voice dictation). The safe area below the input bar varies by device (iPhones with home indicators have 34 pixels of safe area; older devices have none). System UI elements (autocomplete bars, keyboard toolbars) add variable height above the keyboard.

We position the input bar using the keyboard's reported height plus the safe area inset. When the keyboard animates in, the input bar rises with it, matching the keyboard's animation curve and duration. The effect is a single, cohesive upward movement — keyboard and input bar rise together as one unit.

The chat messages above the input bar scroll up to accommodate the keyboard, keeping the most recent messages visible. The scroll is automatic and smooth, ensuring the user can see their last message and the AI's response without manual scrolling.

When the keyboard dismisses, the input bar drops back to its default position above the tab bar, with the safe area padding restored. The entire sequence — keyboard up, keyboard down — must be seamless. Any flicker, jump, or misalignment breaks the illusion that the input bar is a natural part of the keyboard surface.

## Safe area handling

The input bar lives in a complex spatial zone. Below it: the tab bar at 83 pixels, the home indicator (34 pixels on Face ID iPhones), and the screen edge. Above it: the chat messages. To the sides: the screen edges.

The safe area insets on modern devices are the space reserved for the home indicator, the notch, and other system UI. The input bar must respect these insets to avoid being partially hidden behind system elements.

On devices with a home indicator, the tab bar sits above the indicator. The input bar sits above the tab bar. The total distance from the bottom of the screen to the top of the input bar is significant (117+ pixels), which affects the available chat area.

When the keyboard is active, the tab bar is typically hidden (covered by the keyboard), and the input bar sits directly above the keyboard. This reclaims the tab bar's 83 pixels for the keyboard, which would otherwise push the input bar uncomfortably high on the screen.

## Building an adaptive input bar

The input bar is the single highest-interaction component in the app. Users touch it more than any other element. It must be comfortable for extended use, predictable in its behavior, and responsive to every mode it supports.

Test it with long text. Test it with voice input. Test it with every keyboard type. Test it on every device in your support matrix. Test it with one hand. Test it with a phone case that adds thickness. Test it in portrait and landscape.

Forty-eight pixels is not much height. It is enough — if every pixel is perfect.

---

Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. [Plan your next trip](https://app.nowah.xyz).
