CSS border-end-start-radius Property

The CSS border-end-start-radius property controls the curvature of the corner that sits at the intersection of the inline end edge and the block start edge of a box - in other words, it is a "logical" corner radius rather than a physical one. Because it is logical, it describes which corner to round in relation to the flow of text and block progression, so the same declaration automatically targets different physical corners depending on writing mode and direction. Visually, this property shapes the outer box edge and influences how backgrounds and borders appear at that corner when the element is rendered.

The concrete physical corner that border-end-start-radius affects is determined by layout axes and can change when the page uses different text flow settings. Those layout behaviors are driven by properties such as writing-mode (which establishes whether content is laid out horizontally or vertically) and direction (which controls inline progression like left-to-right or right-to-left). Because of this, using the logical radius makes components adapt naturally to internationalization: the same style will round the corresponding corner appropriately in LTR, RTL, horizontal, or vertical writing contexts.

When you combine border-end-start-radius with other radius declarations, it participates in the usual cascade and specificity rules. For example, the shorthand border-radius can set multiple corners at once, but a later or more specific logical longhand will override the corner it targets. Likewise, logical counterparts such as border-end-end-radius and border-start-start-radius let you address other logical corners individually, while physical longhands like border-top-right-radius map to a fixed physical corner irrespective of writing-mode. Mixing logical and physical corner properties can be powerful but requires care, since the same physical corner might be targeted by different logical names under different writing modes.

In practical use, border-end-start-radius is especially useful for building adaptable UI components and themes that must behave consistently across languages and layout directions. It reduces the need for conditional styles or separate rulesets for RTL vs LTR or vertical text, simplifying maintenance. A common pitfall is unintentional overrides when physical and logical properties are combined or when authors forget that the mapped corner changes with writing mode; keeping declarations consistent (either sticking mainly to logical properties or to physical ones) avoids that confusion.