How to Centre Text in a Select (Safari Needs text-align-last)

This article covers how to centre the text inside a select element (<select>).

The short answer: write text-align-last: center. That one line centres the closed state in Chrome, Firefox and Safari. text-align: center on its own does nothing in Safari, and you do not need jQuery for any of it.

I have corrected two things in this article. It used to say that text-align: center was all you needed, and that switching the control to appearance: none made text-align work in Safari. I measured both again and neither is true: appearance: none changes nothing about Safari’s alignment, and text-align-last is what actually fixes it.

A select is a native control drawn by the browser and the operating system, so CSS only reaches part of it. Everything below comes from screenshots I took on 9 October 2026 in Chrome, Firefox and Safari on iOS.

The one line that always works: text-align-last

The short answer: put text-align-last: center on the select. That alone centres the text you can see while the dropdown is closed, in every one of the three browsers I tested.

<select id="centered-select">
  <option value="option1">Option 1</option>
  <option value="option2">Option 2</option>
  <option value="option3">Option 3</option>
</select>

#centered-select {
  text-align: center;      /* for Chrome and Firefox */
  text-align-last: center; /* what makes Safari follow */
}

Writing both is the safe default. text-align alone centres the text in Chrome and Firefox, but Safari ignores it until text-align-last is there.

Going the other way, text-align-last on its own centred the text in all three browsers. If you would rather ship one declaration, ship that one.

/* the single-line version */
#centered-select {
  text-align-last: center;
}

Which declaration works in which browser

The short answer: Safari is the only engine that ignores text-align. text-align-last worked everywhere.

I put “ABC” in a select 300px wide and measured, to the pixel, where the text sat while the control was closed.

▼Position of the text in the closed state (October 2026)

The fifth row is the one to look at. You will often read that turning off the native appearance with appearance: none hands the control back to CSS and makes Safari centre the text. It did not. Styling the control yourself changes how it looks; it does not change the fact that WebKit ignores text-align inside a select.

Why text-align has no effect in Safari

The short answer: WebKit does not apply text-align to the text inside a <select>. This is not a deliberate part of the spec — it is an open bug.

It has been sitting in the WebKit bug tracker since 2010 as “text-align doesn’t work on select tags”, and as of July 2026 the status is still NEW. A WebKit developer put it like this:

We cannot change the text alignment of menu items, but we should honor text-align for the in-page control. This would match the behavior of both Chrome and Firefox.
Bug 40216 – text-align doesn’t work on select tags (WebKit Bugzilla)

In other words: the popup list is off limits, but the control sitting in the page should honour text-align. WebKit agrees that the closed state ought to work. It just has not been made to work yet.

If and when it is fixed, text-align will be enough on its own. Until then, keep text-align-last next to it.

The open option list cannot be centred

The short answer: the list of choices that appears when you open a select cannot be centred with CSS. It is not drawn in the page at all — the operating system draws it as a menu.

The only thing you can centre is the text visible while the select is closed. The WebKit comment quoted above says the same thing: the alignment of menu items is not something the engine can change.

I also checked what happens if you put the style on the <option> instead.

/* writing it here does not reorder the open list */
select option {
  text-align: center;
}

▼What text-align: center on option changes

Opening the list for real in Chrome on macOS, all three options were still left-aligned. The list is painted outside the page as an OS menu, and it happily overflows the window edge. That is why CSS cannot reach it.

The closed state did move, but only in Chrome, because Chrome mirrors the styles of the selected <option> onto the closed control. That is Chrome-only behaviour, so if you want the text centred on purpose, put the declaration on the select.

If the open list genuinely has to be centred, the only route is to drop the native select and build the whole thing from a button and a <ul>. That means rebuilding keyboard handling (arrow keys, Escape to close), screen reader semantics and the mobile picker experience yourself. For a purely visual preference, it is not a trade worth making.

Centring a select you have styled yourself

The short answer: even when you draw the arrow yourself, text-align-last is still what centres the text. On top of that, keep the left and right padding equal.

Here is the full version with the native appearance switched off.

<div class="select-wrap">
  <select id="centered-select">
    <option value="option1">Option 1</option>
    <option value="option2">Option 2</option>
  </select>
</div>

.select-wrap {
  position: relative;
  display: inline-block;
}

.select-wrap select {
  /* stop the browser drawing its own control */
  appearance: none;
  -webkit-appearance: none;

  text-align: center;
  text-align-last: center; /* without this, Safari stays left */

  /* equal padding on both sides so the centre does not shift */
  padding: 8px 32px;
  box-sizing: border-box;
  width: 300px;
  border: 1px solid #ccc;
  border-radius: 4px;
  background: #fff;
  font: inherit;
}

/* draw the arrow */
.select-wrap::after {
  content: "";
  position: absolute;
  top: 50%;
  right: 12px;
  width: 8px;
  height: 8px;
  border-right: 2px solid #666;
  border-bottom: 2px solid #666;
  transform: translateY(-70%) rotate(45deg);
  pointer-events: none;
}

The padding is the part people get wrong. It is tempting to add room only on the right, where the arrow goes, but that pushes the text’s centre to the left. Pad both sides by the same amount and lay the arrow on top with position: absolute.

pointer-events: none is not optional either. Without it the arrow pseudo-element swallows clicks, and clicking that corner of the control does nothing at all.

Checkboxes and radio buttons are the other controls you rebuild from appearance: none. I have written up that process in styling checkboxes and radio buttons with CSS.

Should you centre it at all?

The short answer: form fields are usually easier to read left-aligned. Decide by looking at what the select sits next to, not at the select on its own.

Centre one select while the text inputs beside it stay left-aligned, and the vertical line down the left edge of the form breaks. The form often reads as less tidy, not more.

Centring earns its place when:

In a stacked form, leaving everything left-aligned keeps the reader’s eye travelling down a single edge.

Before you style a select, it is worth asking whether a select is the right control in the first place — the HTML form features worth using today covers the alternatives and the validation that comes with them. For the look of the whole form, Bootstrap and Tailwind compared is relevant too: both ship select styling that already matches their inputs.

Why this article used to be about jQuery

The short answer: this was published as “how to centre a select with jQuery”, and what the jQuery actually did was apply text-align — exactly the same thing the CSS does.

This was the code.

// identical in effect to writing text-align: center in CSS
$(document).ready(function() {
  $('#centered-select').css('text-align', 'center');
});

Because the style lands only after the script has loaded, the control can render left-aligned for a frame and then jump. If all a script does is apply a style, that style belongs in the stylesheet.

And it does not even solve the problem. .css('text-align', 'center') just writes an inline style, which WebKit ignores for exactly the same reason it ignores the stylesheet rule. jQuery cannot work around this one.

Summary

If you are rebuilding your CSS from the ground up rather than patching one control, four books for learning web coding sets out an order to work through.