RIGHT

What it does

RIGHT(text, [num_chars])

RIGHT(text, [num_chars]) returns the last num_chars characters of text.

With n = LEN(text):

RIGHT(t, k)  =  characters at positions n - k + 1 … n      for 0 <= k <= n
RIGHT(t, k)  =  t                                          for k > n
RIGHT(t, 0)  =  ""

The anchoring is what distinguishes it from MID: RIGHT counts from the end, so the window moves when text changes length. MID(t, LEN(t) - k + 1, k) is the same slice written from the other end, and the arithmetic in that expression is precisely the arithmetic RIGHT exists to avoid.

"Character" means one UTF-16 code unit — the unit LEN counts and the unit the Handbook's value universe defines worksheet text in. See The value universe, "Text, exactly".

Arguments

The optional second argument is the family's least uniform feature and worth flagging: RIGHT and LEFT default their count to 1, while MID requires all three of its arguments. A bare RIGHT(A1) is a legal one-character slice; a bare MID(A1, 2) is not a legal call at all.

num_chars is a numeric slot subject to ordinary to-number coercion; see Coercion and lifting.

Try it

Quirks

Result and edge cases

Returns Text.

The boundary rules Microsoft documents on the RIGHT page:

• num_chars must be greater than or equal to zero.
• num_chars greater than the length of text returns all of text — no error, no padding.
• num_chars omitted is treated as 1.

Numbers arriving in text are converted to text first, which is the standard trap for anyone slicing formatted values: RIGHT sees the general-format rendering of the number, not what the cell displays. The cell's number format is presentation and does not reach the function. The to-text rules are shared and only outlined in Coercion and lifting; this is a real gap, not a simplification.

Errors

Note the honest weakness in the first row: Microsoft's page states a requirement on the argument, not the error code produced when it is violated. #VALUE! is what the sibling pages document for the analogous violation, and it is what the Handbook expects — but it is an inference here, and it is on the probe list below.

How to implement

Notes for implementers

The clamp is one-sided and asymmetric with MID: RIGHT clamps an over-long count silently, while MID errors on an under-1 start. An implementation that routes RIGHT through a shared MID kernel has to clamp before computing the start position, or it will turn a documented clamp into an error.

Because num_chars counts code units, RIGHT can split a surrogate pair and return a dangling low surrogate. The value-universe chapter records that ill-formed UTF-16 is a reachable state in this model, so downstream text handling has to survive it rather than assume well-formedness.

RIGHT on a number is a to-text conversion followed by a slice, and the to-text step is the part that is not pinned. Any implementation matching Excel here is really matching Excel's general-format number rendering.

Rust code

7 right_fn "RIGHT" (1, 2) [V "text", V "num_chars"] |s, a, sv| { right(s, a) }

No implementation has been published with a Handbook test suite for this function.

Version differences

No comparison between specific Excel builds is recorded here yet. This does not establish that all builds behave alike.

Alternatives

Relationships

• LEFT is the mirror image, with the same optional-count-defaults-to-1 signature.
• MID is the unanchored slice; RIGHT(t, k) equals MID(t, LEN(t)-k+1, k) within the valid range, and the equivalence breaks at k > LEN(t), where RIGHT clamps and the MID expression computes a start_num below 1 and errors.
• RIGHTB is the byte-counting sibling, documented by Microsoft on the same page and published by the Handbook as its own entry.
• TEXTAFTER is the modern alternative when the tail is delimited rather than counted — TEXTAFTER(a, "@") instead of RIGHT(a, LEN(a) - FIND("@", a)). RIGHT is not superseded; fixed-width tails are still its job.
• Readers confuse RIGHT with TRIM when stripping trailing spaces. RIGHT cannot strip anything — it takes a fixed count from the end regardless of content.

Named variants

No named variants are recorded yet.