Some amounts in a table have two decimals and some don't, and right-aligning still leaves them misaligned—is the decimal point not aligned?

When amount columns in a table look uneven and still look misaligned after right-aligning, it is usually not that a single alignment switch was left off, but that decimal places, numeral shapes, currency symbols, and empty values were not standardized together. Right alignment only puts the right edge of the numbers on the same vertical line; to align the decimal point, you also need tabular figures and consistent decimal places. In 2026 admin delivery, a common practice is: right-align columns that need vertical size comparison, enable tabular figures, and standardize decimal places; keep identifier strings that must be checked digit by digit, such as order numbers and mobile numbers, left-aligned. There is only one criterion: is the user looking at this column to recognize what it is, or to compare how large it is?

Right alignment solves only half the problem; decimal point misalignment is a different issue

Changing a numeric column to right alignment solves digit alignment: when numbers range from three to eight digits, the right edges line up and the left side forms a ragged edge, letting the eye read magnitude down the column without counting digit by digit. This step is a small change, usually just one style rule on the column.

But if you only do this, another kind of skew often appears: in the same column, some amounts show two decimal places while others show integers only. After right-aligning, the decimal points are off by one or two places and look messier than before. The reason is that right alignment aligns the last character, not the decimal point. Either standardize decimal places across the column, or make the decimal point participate in alignment; the former is easier and better matches everyday checking habits.

The other issue is numeral shape. In default fonts, digits are mostly proportional figures: 1 is narrower than 0, so the column looks uneven as digit counts change. After enabling tabular figures, every digit takes the same width, and only then do decimal points fall on the same vertical line. If this column uses a custom numeric font, first confirm whether it supports tabular figures; otherwise the change may not take effect.

Define the column's identity first, then talk about alignment and numeral shape

Alignment is not a global switch for the whole table; it is a column-level attribute. Different columns in the same table can follow different rules, as long as you first clarify what the column is for.

• Identifier type: order numbers, mobile numbers, ID numbers, serial numbers. Users check and compare them digit by digit rather than calculate magnitude, so left alignment is better for digit-by-digit reading; when the length is fixed, tabular figures can be considered.
• Text type: names, notes, addresses, status copy. Keep left-aligned; truncation and expansion for long text are a separate matter.
• Numeric type: amounts, inventory, quantities, ratios, durations. If they need comparison, right-align them, with tabular figures and consistent decimal places.
• Time type: depends on the context. For sorting and finding the most recent record, a consistent format is easier; for reading “which day it is,” left alignment is also fine.

After defining the categories, look again: most so-called misalignment is actually concentrated in two or three numeric columns and does not require reworking the whole table. Counting how many columns truly need size comparison is the first criterion for deciding whether this change is worth doing.

Decimal places, symbols, and empty values: if any of the three is inconsistent, the work is wasted

These three issues are noticed first during acceptance, and they often surface only after alignment has been changed.

• Decimal places: standardize the whole column to the same level, for example two decimals for amounts and one for ratios; if a few values really need more digits, put them in a separate column or in the details, not mixed into the same column.
• Currency symbols: place symbols consistently to the left of the value with a fixed width, and do not include them in right alignment; when the whole column uses one currency, you can also move the unit to the header and leave only numbers in the cells.
• Empty values: use a consistent placeholder (such as an en dash) and right-align it the same way; otherwise blank rows break the ragged edge, and users may think the data did not load.

These three are consistency at the rules level. Changing them is mostly configuration and copy conventions, so the cost is low; but if any one is missed, the earlier alignment work looks unfinished.

A sequence you can follow for checking

You do not need to redraw the table from scratch. Follow the five steps below; most projects can finish within one or two iterations, and it is less likely to affect other modules.

1. Define purpose: for each column, ask, “Is the user recognizing it, or comparing it?” Columns for size comparison go to the next step; the rest stay left-aligned.
2. Define alignment: right-align numeric columns, and right-align the header as well. Left-aligned headers with right-aligned cells are a common visual break.
3. Define numeral shape: enable tabular figures for numeric columns; the wider the range of digit counts, the more necessary it is. Small numeric columns with two or three digits can be left for later.
4. Define decimal places and symbols: standardize decimal places across the column, and keep currency symbols, percent signs, and thousands separators consistent across the table.
5. Check empty values: use a consistent placeholder and right-align it the same way; run it with real data before acceptance.

The logic of this sequence is: purpose determines alignment, alignment determines numeral shape, and numeral shape determines how symbols and empty values are handled. If you skip steps, you can end up with “alignment changed but it looks messier.” Step five is often missed, yet it is exactly the thing noticed first during acceptance.

Delivery scene: which columns to change first when the schedule is tight

In an admin redesign done in 2026, the table had only one or two iterations in the schedule, and the table used a shared component. Changing global styles would affect other business pages, so developers were unwilling to change it. The approach at the time was not to touch the component defaults, but to attach alignment and numeral-shape configuration separately to three types of columns: amounts, inventory, and ratios. We validated them on one finance page and one inventory page first, then decided whether to roll them out. The result was that horizontal comparison on these two high-frequency pages became noticeably easier. But one column used a custom numeric font, and because its numeral-shape support had not been confirmed first, the decimal point was still misaligned after launch, requiring one round of rework to fix. The lesson: before changing styles, verify the font's numeral-shape support clearly.

Based on the experience range for this kind of admin project in 2026, the options and costs can be roughly divided as follows:

• Alignment only: adjust only the alignment of numeric columns and headers. The workload is typically within half a day. The benefit is that magnitudes can be scanned, but decimal point misalignment is not solved.
• Alignment plus numeral shape and decimal places: add tabular figures and consistent decimal places across the column. The workload is typically one to two working days. The benefit is decimal point alignment, suitable for finance, cost, and inventory pages.
• Standardize symbols and empty values as well: also standardize currency symbols, percent signs, thousands separators, and empty-value placeholders. This typically falls within two to four working days and suits scenarios where report templates will be reused long-term.

These three levels are not about doing as much as possible; it depends on whether the table will be used long-term and whether anyone will make decisions with it. For pages used only for display and not for decisions, the first level is usually enough.

Applicable scenarios and boundaries

Number alignment is worth doing, but it has clear conditions; not every table should add it.

• Suitable: admin tables that need vertical number comparison, financial reports, price-comparison and cost-accounting pages, inventory usage statistics; cases with more than two numeric columns on one screen and a wide range of digit counts.
• Not necessary: columns where the digit count is fixed and very short (such as years or ratings); mobile layouts already changed to one record per card with field names before values; large dashboard numbers used only for display, not decisions.
• Solve something else first: a column mixes text and numbers, such as “about 3 days” or “TBD.” Standardize the data first, then talk about alignment; forcing right alignment will only make the text messier.

The boundary can be remembered as one sentence: number alignment serves comparison, not recognition; when users will not compare sizes within the same column, this change can be postponed. That sentence is more useful in reviews than any debate about how it looks.

Frequently asked questions

The amount column is already right-aligned; why are the decimal points still misaligned?

It is usually because decimal places are not standardized across the column, or proportional figures are being used. First standardize decimal places to the same level, then enable tabular figures for the column; only then will the decimal points fall on the same vertical line.

Do all number columns in a table need to be right-aligned?

No. Only columns where users compare sizes vertically need right alignment; for IDs and years with fixed digit counts that are used only for recognition, keeping them left-aligned is better for digit-by-digit checking.

Should currency symbols be right-aligned together with the numbers?

A common practice is to place symbols consistently to the left of the value with a fixed width and not include them in right alignment; when the whole column uses one currency, you can also move the unit to the header and leave only numbers in the cells.

Will enabling tabular figures look odd?

It generally looks neater only within numeric columns; it was designed for alignment in the first place. If you are worried about appearance, use it first only in columns such as amounts and ratios, and keep default figures for numbers in body text.

If you have a table that looks uneven right now, start with the amount and quantity columns: change to right alignment, enable tabular figures, standardize decimal places, then check symbols and empty values, and run it with real data before deciding whether to roll it out. This approach has clear benefits for admin pages that need size comparison; for columns that are mainly for recognition and have fixed digit counts, you can leave them alone for now.