How to Hide HTML5 Number Input Spin Buttons with CSS

By the end of this page, you will understand how browser UI for <input type="number"> works, how developers commonly hide the spin buttons with CSS, what browser limitations exist, and when using type="number" is still the right choice.

The main concept here is browser-native form control styling.

When you use:

<input type="number">

most browsers do more than just validate numeric input. They often add built-in interface features such as:

• spin buttons (up/down arrows)
• numeric keyboard support on some devices
• built-in validation rules for numbers
• support for min, max, and step

The important thing to understand is that these controls are rendered differently by each browser engine. That is why there is no single universal CSS rule that works identically everywhere.

In practice, hiding the spin box usually requires browser-specific CSS, especially for WebKit-based browsers like Chrome, Safari, and Edge.

This matters in real programming because form controls often need to match a design system. Developers frequently want the behavior of a numeric field without the browser’s default arrows. However, removing native UI also means you should think carefully about usability and accessibility.

Think of <input type="number"> as a standard text box that the browser has wrapped in its own mini control panel.

That control panel may include:

• number validation
• increment/decrement arrows
• special mobile keyboard behavior

Your CSS can often repaint or hide parts of that panel, but the exact switches depend on the browser. So instead of controlling one plain box, you are styling a box with browser-installed attachments.

A simple analogy:

• type="text" = a plain notebook page
• type="number" = the same page, but with built-in ruler, arrows, and validation tools added by the browser

If you want to remove one tool, such as the arrows, you often need browser-specific instructions.

To hide spin buttons, developers usually target browser-specific pseudo-elements.

Common CSS for WebKit browsers

<input id="test" type="number">

/* Chrome, Safari, Edge, Opera */
input[type="number"]::-webkit-outer-spin-button,
input[type="number"]::-webkit-inner-spin-button {
  -webkit-appearance: none;
  margin: 0;
}

This removes the visible spin buttons in browsers that support these WebKit pseudo-elements.

Firefox approach

Firefox uses a different rule:

input[type="number"] {
  -moz-appearance: textfield;
}

This makes the number input look more like a regular text field, which removes Firefox’s default number styling.

Combined example

<input id="test" type="number" =>

Consider this example:

<input type="number" id="quantity" min="1" max="10" step="1">

input[type="number"]::-webkit-outer-spin-button,
input[type="number"]::-webkit-inner-spin-button {
  -webkit-appearance: none;
  margin: 0;
}

input[type="number"] {
  -moz-appearance: textfield;
}

Here is what happens step by step:

1. The browser reads <input type="number">.
2. Because the type is number, the browser applies native number input behavior.
3. In Chrome-like browsers, the browser normally attaches inner and outer spin button elements.
4. Your CSS targets those internal pseudo-elements:
   • ::-webkit-outer-spin-button
   • ::-webkit-inner-spin-button
5. -webkit-appearance: none; tells the browser not to render them with the default look.

Developers commonly hide number input spin buttons in situations like these:

• Custom design systems: A product team wants all fields to have a consistent visual style.
• Checkout forms: Quantity, ZIP-like numeric fields, or price inputs may need a clean appearance.
• Admin dashboards: Numeric filters and settings fields often use custom controls instead of native arrows.
• Mobile-friendly forms: Teams may want numeric keyboards without showing desktop spin controls.
• Component libraries: A reusable input component may hide native controls and replace them with custom buttons.

Example: a shopping cart quantity field might use type="number" for numeric validation, but the UI may show custom + and - buttons outside the input instead of the browser’s default arrows.

In real projects, developers usually handle this in a shared form stylesheet or UI component.

Common patterns include:

• Global input reset for all number fields:

input[type="number"]::-webkit-outer-spin-button,
input[type="number"]::-webkit-inner-spin-button {
  -webkit-appearance: none;
  margin: 0;
}

input[type="number"] {
  -moz-appearance: textfield;
}

• Scoped component styling so only certain fields are affected:

.quantity-input::-webkit-outer-spin-button,
.quantity-input::-webkit-inner-spin-button {
  -webkit-appearance: none;
  margin: 0;
}

.quantity-input {
  -moz-appearance: textfield;
}

• Validation plus custom UI: teams keep type="number" for built-in validation and add custom increment/decrement buttons.

• Guarding user input in JavaScript:

const input = .();

input.(,  {
   value = (input.);
   (value < ) input. = ;
});

1. Expecting one CSS rule to work everywhere

This is the biggest misconception.

Broken expectation:

input[type="number"] {
  appearance: none;
}

Why it is a problem:

• browser support differs
• native controls are implemented differently
• one generic rule may not hide the arrows consistently

2. Forgetting Firefox-specific styling

Some developers only write WebKit rules:

input[type="number"]::-webkit-outer-spin-button,
input[type="number"]::-webkit-inner-spin-button {
  -webkit-appearance: none;
}

This may work in Chrome but not Firefox.

Use both WebKit and Firefox approaches when needed.

3. Using JavaScript for a CSS problem

This is unnecessary in most cases.

Avoid solutions like repeatedly modifying styles in JavaScript just to hide arrows. CSS is cleaner and faster.

4. Confusing visual appearance with input behavior

Even after hiding spin buttons, the input is still:

• a number field
• subject to numeric validation
• potentially affected by wheel or keyboard increment behavior

5. Replacing with without thinking through the trade-off

<input type="number">

/* Chrome, Safari, Edge, Opera */
input[type="number"]::-webkit-outer-spin-button,
input[type="number"]::-webkit-inner-spin-button {
  -webkit-appearance: none;
  margin: 0;
}

/* Firefox */
input[type="number"] {
  -moz-appearance: textfield;
}

Quick rules

• Use CSS, not JavaScript, to hide spin buttons.
• WebKit browsers need ::-webkit-inner-spin-button and ::-webkit-outer-spin-button.
• Firefox commonly uses -moz-appearance: textfield.
• Hiding arrows does not change the input type.
• type="number" still keeps number validation and min/max/step behavior.

Remember

• No single perfectly universal rule exists for all engines.

Can I hide the spin buttons on a number input with CSS?

Yes. In Chrome, Safari, Edge, and similar browsers, developers usually hide them with WebKit pseudo-elements. Firefox typically needs a different appearance rule.

Is there a fully universal cross-browser solution?

Not exactly. The usual solution is cross-browser in practice, but it relies on browser-specific CSS because each engine renders number inputs differently.

Do I need JavaScript to remove the arrows?

Usually no. This is mainly a styling task, so CSS is the standard solution.

If I hide the arrows, is it still a number input?

Yes. The field remains type="number", so browser validation and numeric behavior still apply.

Why do browsers show spin buttons in the first place?

They are part of the native UI for numeric input and allow users to increment or decrement values.

Should I use type="text" instead of type="number"?

Only if you need complete control and are willing to handle validation yourself. Otherwise, type="number" is usually better for semantics and built-in constraints.

Can users still change values with the keyboard or mouse wheel?

Sometimes yes. Hiding the arrows only affects appearance, not all number-input behaviors.

• HTML input types — Different input types provide different built-in browser behaviors.
• CSS vendor prefixes — Hiding spin buttons often requires browser-specific prefixed rules.
• Pseudo-elements — WebKit spin buttons are targeted through special pseudo-elements.
• Form validation — type="number" affects how browsers validate user input.
• Accessibility in forms — Removing native UI can affect how users interact with inputs.
• Custom form components — Teams often replace native number controls with reusable styled components.
• min, max, and step attributes — These work closely with number inputs and their increment behavior.