Saying Goodbye to Rounded Corners: Back to Sharp Edges

Today, rounded corners are standard almost everywhere: on buttons, cards, modals, table headers, badges, and tooltips. Precisely because they are so widespread, many interfaces now look very similar.

We are shifting webconsulting.at to sharp edges. The reasons are both design-related and technical: more usable area in compact components, a consistent geometry, and fewer CSS exceptions. This decision applies to our own website and our tools. It is not a general recommendation against rounded corners.

Table of Contents  

Why now?  

With mobile user interfaces and Soft UI, rounded corners have become established in many design systems. Frameworks and component libraries deliver them as a default setting for buttons, input fields, and panels. If you do not specify otherwise, you get rounded corners in practically all components.

As a result, rounding carries less design meaning than it used to. An interface with default rounding mainly shows which presets a project has adopted.

For webconsulting.at, we want to deliberately define our visual language. Sharp edges support a clear grid; the visual hierarchy is created through typography, contrast, and spacing.

What rounded corners mean in practice  

Rounded corners do not just affect visual appeal. They also make a difference in the technical maintenance of components. Four points tipped the scales in our decision.

1. Loss of space at the edges  

Every radius takes away usable area at the corners. In compact components such as toolbars, badges, table headers, or icon buttons, content must therefore shift further inwards. A sharp-edged container, by contrast, offers the full rectangular area.

2. Icons in the curve  

If an icon, a status dot, or a control element sits close to a rounded corner, it quickly looks clipped. This then requires additional padding, absolute positioning, or custom positioning areas. With sharp edges, this effort is largely eliminated because the geometry remains orthogonal and predictable.

3. Unintended radius cascades  

CSS and utility classes readily pass down radii across multiple levels. Just a rounded-* on a parent element, a theme token on --radius, or a component default on th creates curves in places where they were never intended.

A typical example is table headers rounded on both sides. Where adjacent curves meet, double arches occur that do not fit the grid. Such areas have to be manually corrected individually, making maintenance more time-consuming.

4. Inconsistency across system boundaries  

Design tokens, Tailwind utilities, component libraries, and embedded charts often bring their own individual radius values. As a result, different degrees of curvature sit side-by-side, and the interface loses its unified visual language.

A single shared value solves this problem regardless of what that value is. We chose 0 because radius 0 gives all systems the same unambiguous starting point and has no gradations.

Design requirements  

A sharp-edged interface is less forgiving. Typography, spacing, contrast, and hierarchy must be precise.

Rounded corners can visually soften minor discrepancies in spacing or visual hierarchy. Once the curve is removed, tight spacing, inconsistent padding, and an unclear hierarchy become noticeable much more quickly. That is a genuine advantage of rounded corners, and it belongs in the equation.

Therefore, as part of this transition, we are also revising these fundamentals. The visual quality of the interface must come from the content, grid, and typography.

Implementation on webconsulting.at  

Our standard for this website is clear: Radius 0 across the entire design system.

Specifically, this means:

1. We set the design tokens (--radius* and related variables) to 0.
2. A downstream CSS layer enforces sharp edges even where utilities or components still bring along rounded-* styles.
3. Diagram and chart chrome (including Mermaid nodes) follow the same rule.
4. New components start with radius 0 by default. Any deviations are explicitly defined.

:root {
--radius: 0;
--radius-sm: 0;
--radius-md: 0;
--radius-lg: 0;
/* … additional radius tokens to 0 … */
}

*,
*::before,
*::after {
border-radius: 0;
}

It is crucial to apply this rule system-wide. If individual areas retain other radius values, an inconsistent look returns.

Desiderio: the radius remains configurable  

Radius 0 is a decision for our own website. Our upcoming TYPO3 template system Desiderio deliberately does not make this decision for its users: there, the radius remains a perfectly normal theme setting.

The model for this is shadcn/ui, the component library by shadcn. In its theme editor at ui.shadcn.com/create, the radius is a value like any other, with the options Default, None, Small, Medium, and Large. Whoever assembles a theme decides for themselves how strong the rounding should be. In the frontend community there is a half-serious saying about this: “shadcn is always right”. On this point we agree: a template system that serves many different sites should not answer a fundamental design question the same way for every project. That is why we kept the option in Desiderio.

Desiderio adopts the model of the shadcn theme editor as a site setting: None, Small, Medium, Large, plus an additional Full. Without an explicit choice, the radius of the selected shadcn preset applies. Technically, Desiderio writes the setting as a data-radius attribute on the body element; a CSS variable distributes the value to all components. A change takes effect immediately across the entire site, with no build step and no deployment.

body[data-radius="none"] { --radius: 0rem; }
body[data-radius="sm"]   { --radius: 0.375rem; }
body[data-radius="md"]   { --radius: 0.625rem; }
body[data-radius="lg"]   { --radius: 0.75rem; }
body[data-radius="full"] { --radius: 1rem; }

The following screenshots show the same Desiderio element with three different radius values. Cards, badges, and buttons each follow the same token:

This covers both paths: webconsulting.at consistently uses radius 0, and Desiderio projects choose the value that fits their brand. More about the template system in our article on Desiderio.

Conclusion  

Rounded corners remain a perfectly workable standard. Most component libraries support them well, and many users expect them. For webconsulting.at, we nevertheless chose radius 0:

• Many websites look similar because of the same default rounding.
• In small UI elements, less space remains for content.
• Icons and control elements often require additional spacing or custom positioning.
• CSS rules can inadvertently pass down radii to child elements.

Sharp edges alone do not make an interface good. In fact, clear typography, clean grids, consistent spacing, and sufficient contrast become even more critical. We are focusing on these fundamentals in the ongoing development of our design system.

On webconsulting.at, radius 0 is thus the binding standard, and exceptions require a justification. In Desiderio projects, the choice remains open: there, the radius is a setting, not a dogma.