A select box looks different from an input when browser defaults, native arrows, height rules, font inheritance, and padding do not match the rest of the form system.
CSS form fixWhy does a select box look different from an input?
A select box looks different from an input because it is a native form control with browser styling, built-in arrow space, platform-specific rendering, and sometimes different font or line-height behavior. The input and the select may share a border, but the browser may still draw them like two different products.
The fix is not to fight every native detail blindly. The production move is to create a shared field system, give the select the same height, padding, font, border, and background rules, then reserve clean space for the arrow so the text does not crash into the control.
Quick diagnosis
If the select looks shorter, taller, darker, or misaligned beside an input, compare computed font, line-height, padding, border, appearance, and arrow space.
Browser defaults leak in
The select may keep native padding, background, or platform arrow styling.
Heights do not match
Inputs and selects often need the same min-height and line-height strategy.
Text is not inherited
Select controls may not inherit the same font unless you tell them to.
Arrow needs room
The select text can collide with the arrow when padding-right is too small.
Mobile differs
Mobile browsers may render select controls differently from desktop.
The fix is a field system
Treat input and select as siblings in one design system, not separate one-off elements.
Test input and select side by side
Place a normal input and a select in the same row, then inspect their computed styles. If the height, font, padding, or background differs, the mismatch is coming from form-control defaults, not from the grid itself.
Related: Try this in the FrontFixer Live Inspector.
Open Live Inspector →The select arrow has no reserved space
A select needs room for the arrow. Without right padding, long option text can run into the native icon or custom arrow area.
Broken code
text hits arrowCorrect code
arrow paddingBroken visual result
Fixed visual result
The select uses a different font or line-height
Native controls can ignore the visual rhythm of your page when font and line-height are not inherited consistently.
Broken code
font mismatchCorrect code
inherited textBroken visual result
Fixed visual result
The select breaks differently on mobile
Mobile browsers may keep native select behavior. The safe fix is to make the outer form system consistent while respecting platform behavior.
Broken code
desktop-only stylingCorrect code
touch friendlyBroken visual result
Fixed visual result
Fast practical rule
Do not style inputs and selects as separate worlds. Create one shared field rule, inherit typography, reserve arrow space, and keep mobile tap targets large enough to feel intentional.
Native is not bad
The goal is not to erase every native behavior. The goal is to make the control fit your system.
Start shared
Apply core field styles to input, select, and textarea together.
Reserve arrow room
A select needs extra inline space for its arrow or custom icon.
Test states
Check focus, disabled, error, and mobile states before shipping.
Debug checklist
- Compare input and select computed height.
- Make all controls use
font: inherit. - Use one shared border, radius, and background system.
- Reserve padding for the select arrow.
- Avoid tiny fixed heights on mobile.
- Check focus ring consistency.
- Test disabled and error states.
- Do not over-customize native select behavior when platform behavior is useful.
Related fixes that can help
Select styling bugs often connect to form spacing, input widths, placeholder clipping, and responsive form rows.
Final takeaway
A select box looks different from an input when browser defaults and field-system rules are fighting each other. Give inputs and selects one shared shell, inherit typography, protect arrow space, and test the form on mobile before treating the mismatch as a mystery.