What? Another article about centering?! But all we have to do is use display: flex | grid, then align-items: center. No, it’s align-content… wait… I think it’s justify-content. Well, let’s use margin: auto, this one works all the time, right?
Despite the countless number of online resources (even CSS-Tricks has a full guide on it), it’s easy to get confused when trying to center an element, whether vertically, horizontally, or both). I am sure you will find something that works by googling or trying different combinations. But do you really understand why the code you picked works? Is it the right one for your use case? Because it really does depend and require consideration!
In this article, we will do a fresh exploration of centering in CSS, and hopefully, you will learn something new by the end of it.
I already master CSS centering. Should I skip this article?
Stay with me because we will explore hidden tricks and modern features that you may not know — safe centering, text-box, centering in anchor positioning, etc.
No, centering is not hard. Considering all the different and various ways to center an element, it’s an easy task that generally requires two or three lines of code. But, how many ways do we have to center an element? I did the count, and I was able to enumerate 100 different ways to center an element vertically and horizontally within a container.
Are you serious,100 ways?! That’s insane.
Yes, 100 is a ridiculously high number for what should be a simple task, but that number is misleading. If you check the list, you will find I marked about 60 of them in red, meaning they are hacky and not recommended. This leaves us with roughly 30 valid approaches. And within those valid options, many are basically the same, only written differently, so we can consider them redundant.
At the end of the day, the number of “unique” and “valid” ways to center an element is less than 15 (or even 10) but it was a fun exercise enumerating the different codes that can center an element. Go check the full list, you may learn something new!
Let’s look at things from a beginner’s perspective. For me, who has been writing CSS day and night for years, it’s easy to say “centering is not hard,” but what about to a newcomer who reads this and confronted with all those different ways to center stuff? Nah, it’s not easy at all. align-items, align-content, justify-content, place-self, margin: auto. What the hell?!
Too many properties for a task that everyone claims is easy! Well, let’s pick a code that works and move on. After all, if the item is in the center, then it’s fine, right? Let’s avoid making a lot of noise around this, or the CSS fanatics will shout at me.
Don’t think that way! Centering can be hard, and that’s fine. It doesn’t mean you are stupid. It simply means you need to understand how it works.
Don’t skip the important step of “learning” (like many do); otherwise you will find yourself doing a lot of copy/paste without really understanding what is going on. Sometimes it works, but sometimes it doesn’t, and it can be very frustrating.
Centering is nothing but a special case of alignment in CSS, and alignment is a complex world. It’s not only left, center, right, or top, center, bottom. It’s more than that. The good news is that you can easily learn it. For this purpose, I wrote a deep dive I called “The fundamentals of alignment in CSS.”
It’s probably one of my longest writings, but believe me, it’s worth your time (and effort). I explain how alignment works in all the different CSS layout methods. It starts with understanding the alignment theory, which has two levels of alignment (“content” and “item”) and two axes (horizontal and vertical).
Identifying the “content” and the “item” in every layout is the key to understanding how everything works. I insist on “every layout” because assuming it works the same everywhere is a very common mistake.
Do yourself a favor and read that detailed article — you will thank me later! And once you understand the core concept of alignment, centering will become child’s play.
I see a lot of people who always use the same method to center an element, whatever the situation. You have the CSS Grid team and the Flexbox team. While both work, I don’t advise you to think that way. Remember that the goal is to understand and avoid quick copy/paste approaches.
Study your layout and your requirements, then decide which method to use. Maybe your case requires position: absolute or a simple text-align: center. Flexbox or CSS Grid aren’t always mandatory for centering stuff, and there is no one way that’s better than another.
That said, if I have to pick something, I would consider the following codes. Each one for each type of layout.
.container {
display: block;
align-content: center;
justify-items: center;
}
.container {
display: grid;
place-content: center;
}
.container {
display: flex;
flex-wrap: wrap;
place-content: center;
}Note: justify-items in the context of a block container is not supported by all the browsers. It’s Chrome-only for now, so consider using Chrome to see the following demos.
The properties are defined in one place (the container), and the methods are suitable for centering one or multiple items.
You won’t notice a difference when centering a single item. The three methods behave the same.
With multiple items, Flexbox behaves differently. It has a responsive behavior where the items are initially laid out horizontally and wrap when the container is narrowed. Resize the container and see what happens.
And with multiple items of different sizes, they all behave differently.
We started with three approaches that give us the same “visual” result when working with a single item, but upon adding more items, we can clearly see they are different. This difference is important as it shows that it’s not about picking a random code to center stuff. It’s about understanding how each code behaves in different situations, then picking the most suitable one. It’s wrong to assume that we can center the same way using Flexbox, CSS Grid, etc. All the methods are different and rely on different mechanisms, even if they give the same result in the context of one item.
This also explains why we technically have 100 ways to center stuff. We have different layout types, and each layout has its own alignment logic. But when the structure is reduced to one item inside a container, we have a lot of choices, and many methods may look identical even though they are not.
So, let me repeat myself: Study the alignment logic behind each code to know which one is suitable for your use case. Don’t blindly copy/paste a code that simply “works.”
When centering “boxes,” we generally don’t have any issues if we apply the properties correctly. But once we start dealing with text, it can be tricky to perfectly center things vertically. You know the extra space above or below that you cannot really control and you have to use magic values for line-height or padding to rectify it.
We now have a new property that allows us to fix this: text-box. It trims the extra space based on your configuration.
In both boxes, I align the content in the center using a common code. Notice that the first box is not that good. The text seems to be off, even though I am using the CSS properties correctly.
It’s frustrating, right? For CSS, everything is perfectly centered, but for us, it’s not. why!?
It’s related to how the font is designed and the space reserved for each character. Adding a border around the text will make things clear.
As you can see, the “text box” is centered, but there is unwanted space inside it. I was able to remove that space using one line of code:
text-box: cap alphabetic;Let’s try lowercase text without descenders or ascenders.
This time I am using slightly different keywords:
text-box: ex alphabetic;…to remove the space for perfect centering
The values look strange and unintuitive, but I have created a small generator where you can easily specify which space you want to trim and get the code in no time.
And if you want more detail on that feature, check Danny Schwarz’s “Two CSS Properties for Trimming Text Box Whitespace.”
In some cases, you may need to use absolute or fixed position, which means we are dealing with an out-of-flow element and a different alignment logic; hence, another centering technique.
The common way to do that is the classic top/left combined with translate:
left: 50%;
top: 50%;
transform: translate(-50%, -50%);It works, and everyone is happy, but it’s not the suitable code to use. In 2026, I would consider that code hacky, and worth avoiding. It’s like creating layouts using float. That a was a valid approach until we got Flexbox and CSS Grid, which were intentionally designed for this sort for thing.
It’s the same thing with absolutely-positioned elements. Today, it’s better to rely on modern CSS features like this:
inset: 0;
place-self: center;The inset property controls the “inset modified containing block” (IMCB) and place-self (the shorthand for justify-self and align-self) aligns the element inside the IMCB. I explain all those concepts in great detail in this article.
Where is anchor positioning in all of this?
Great question! Anchor positioning relies on absolute (or fixed) elements and has its own mechanism for controlling an element’s placement relative to its anchor. We are specifically dealing with centering, so we have to talk about a new value, anchor-center.
Let’s start with the following example:
I am placing the text box above the anchor using position-area: top. You can drag the anchor, and the text box will remain stuck to the top and centered.
Let’s update the alignment and use place-self: center.
The position looks a bit off at first glance, but if you drag the anchor and look closely, you will see the box centered within the top area.
Centering is indeed not easy! It’s confusing if you don’t know in which area your element is centered. You will think that something is broken because your eyes might not see it as a centered element.
If you want to get back to the previous position, you can use this:
place-self: end anchor-center;…or this:
align-self: end;
justify-self: anchor-center;What’s happening here is that, vertically, we place the element at the end (the bottom), and horizontally, we consider the center of the anchor element. In other words, the anchor-center value is what makes the element follow the anchor when you drag it!
This means we have two different ways to use anchor positioning for centering: Either (1) center relative to the selected area using the center value, or (2) center relative to the anchor using the anchor-center value.
You will rarely need to use the anchor-center value in most cases because anchor positioning comes with area-specific default alignment. Setting position-area should be enough, but it’s good to know how to adjust the alignment and understand the difference between center and anchor-center.
If you want to explore alignment in anchor positioning, I have create an interactive demo that allows you to set the area, adjust the alignment, and see the result. There are 36 different positions you can set using position-area and five alignment values per axis.
You are probably wondering what safety has to do with centering, right? Don’t worry, centering doesn’t present security risks, per se, but it can be a risky thing for your content!
Take the following example:
I am using CSS Grid to center a red square within a container and we have two situations. The red square is smaller than the container (a classic situation), and the red square is bigger than the container (a less common situation).
In both situations, the red square remains centered, i.e., its center point matches the container’s center point. This is an unsafe centering approach, and yet it’s the default behavior of many centering methods.
Why is it unsafe? The content inside the container is overflowing from all sides, so if you decide to hide the overflow and add a scrollbar, some parts of the content cannot be reached, which is a form of data loss. In this case, the top and left parts are lost. That’s what I mean by unsafe.
Try scrolling the second container, and you will notice that you cannot see the red square’s top and left borders.
We can fix this by using safe alignment like this:
place-content: safe center;Now, when an overflow occurs, the browser will shift the element to a “safer” position that displays the whole content in case we need to scroll. In other words, the browser prioritizes content visibility over centering (the exact opposite of an unsafe alignment).
I know what you’re probably thinking, and you shouldn’t be thinking that! Adding safe everywhere isn’t a good idea. Sometimes the unsafe behavior is actually what we want, so only consider safewhen you’re faced with content obstruction.
Let’s get back to the anchor positioning demo:
If you drag the anchor closer to the edges, the box is stopped by those edges (the containing block) and the default alignment is lost!
In anchor positioning, the default behavior is safe alignment. If you don’t know about it, you may spend a lot of time trying to figure out why the element is not centered.
You can change that behavior using the unsafe keyword:
place-self: unsafe end unsafe anchor-center;Or:
justify-self: unsafe anchor-center;
align-self: unsafe end;Now, the browser allows the box to overflow the container. It will prioritize alignment over potential content loss due to the overflow.
And if you think it’s useless to work with an unsafe alignment in anchor positioning, then you are wrong. Here is one use case where I needed to switch to an unsafe alignment. We have a sticky header with a small icon next to the website title that you can hover to show a tooltip. The sticky header creates a containing block for the tooltip and, by default, prevents it from overflowing its boundary. I had to use an unsafe alignment to allow the overflow and keep the tooltip correctly placed.
I know it can be confusing, but you will rarely need to mess with safety. Keep using the default browser behavior, but remember you have the safe and unsafe values you can use to rectify a misalignment.
I hope that after this article you will see centering from a different angle. It’s not about picking a code that works, and you’re done. It’s about understanding how alignment works, considering your specific use case and layout, picking the appropriate code, and, more importantly, understanding why it works.
The State of CSS Centering in 2026 originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.
Let’s play a quick game: I’ll show a graph and try to guess what it’s about.
No, it isn’t a crypto coin crashing a few hours after being minted. And not, it is also not an oscillatory/wavy graph made with pure CSS, but a harsher truth.
I already gave it away with the title, but it still hits like a ton of bricks to know it is the steep decline in the number of questions asked on Stack Overflow. You can see its peak around 2014 with more than 200,000 questions asked in a single month. But now in 2026, it is struggling to even hit 3,000 questions a month.
We don’t have to be experts in the field to find out the culprit. You guessed, it’s AI… mostly.
While AI is painted as the Stack Overflow killer, the truth is Stack Overflow’s downfall started long before ChatGPT’s release in late 2022.
By community accounts and also from personal experience, moderation since its peak in 2014 has been (and still is) one of the leading causes for the lack of questions.
As the site grew, Stack Overflow needed a better way to moderate the hundreds of thousands of questions asked every month: the inevitable wall that forum-based communities hit when they scale beyond a certain point. There are several ways to try to solve this, but the route Stack Overflow took might not have been the best:
On Stack Overflow, we close or delete questions that can’t be answered straight away – it’s not very sociable, but it scales wonderfully.
It’s clear Stack Overflow wasn’t focusing on the quantity of the questions but rather on the quality of them, while avoiding duplicates as much as possible. This pattern was in favor of Google searches for questions that were already answered and, hence, living on pre-answered questions instead of on users making new or duplicate ones.
It wasn’t helpful either how the community seemed to close upon itself, making it harder for beginners to even ask a question. And if you’re like me, you probably want to inquire without being told you’re stupid, as if getting punished for wanting to learn.
Generative AI was the final nail in the coffin. I can’t complain about this, as AI seemingly provides the same answers without judgment (in fact, maybe too much encouragement) nor delay, so I can see why people might prefer asking an LLM instead.
However, as I dug deeper into this, my concern was no longer about just Stack Overflow, but the tech ecosystem at large. Questions like, are we still asking questions? Are we still seeking to be better? Or do we all rely on LLMs, and solely on LLMs, for advice? That kept ringing in my mind as I continued my research.
I believe that, beyond the fall of Stack Overflow, those questions linger more than ever. How AI has generally impacted our workflow, how we can use it in problem-solving, and what we can do about this as developers.
Is AI a better programmer than you? What makes a programmer better than others is as subjective as it gets, but some are eager to say that AI can write code better than you. According to that research:
AlphaCode achieves human-level problem solving skills and code writing ability as shown by performance in programming competitions.
At least that’s when it was tested against Codeforce’s (an online code competition site) problems, where I admit it can and will perform better than your average programmer. But most developers don’t care about Contest problems beyond a technical interview; they know being a software developer is so much more than that.
AI writing quality code is an extremely nuanced topic and lacks a decisive conclusion. However, if you take the time to research, you’ll find that AI-generated code has lots of flagrant differences. According to the research from Cornell:
AI-generated code is generally simpler and more repetitive, yet more prone to unused constructs and hardcoded debugging, while human-written code exhibits greater structural complexity and a higher concentration of maintainability issues.
Okay, so it can generate simple code, but can it write good code? Even solve problems better than a software engineer would?
According to MIT research, AI can write good code, but it cannot possibly think and make decisions like a software engineer. AI cannot compete on that level yet, at least without running into a lot of bugs.
Drawing on both first-hand experience and feedback, if all you do is copy-and-paste AI-generated code without careful consideration, you are bound to hit serious bugs and possibly even vulnerabilities. In fact, VeraCode published an article stating that “[…] 45% of AI-generated code contains security flaws,” after testing for security vulnerabilities in 100 AI models. That’s a large percentage of code that’s flawed security-wise and would have cost implications for any user who wants to “vibe-code” without doing thorough checks.
Fun fact: GitHub released the results of its AI in software development survey in August 2024, and over 97% of its respondents have used AI outside or inside their work. That’s even aside from the companies enforcing the use of AI in your current code workflow. It’s literally everywhere; there’s almost no escaping its usage
But, does that mean it’s all bad? The answer to that, in my opinion, is no. According to research done by Harvard Business Review, AI is effective for helping solve problems (let’s not also ignore the trade-off from the study that AI workflows result in less motivation). In essence, it is perhaps best used to enhance problem-solving effectiveness.
This means that, as AI is taking over industries and being incorporated into our daily work, it still won’t replace your creativity and problem-solving approach, which you would need to tackle unique everyday challenges. It’s difficult to replicate.
Like every other tool, AI has its limits, and without human craftsmanship behind it, the tool is almost useless. A good craftsman uses all the tools at his disposal to achieve his goals, AI being just one of them.
“The effectiveness of the tool is determined by the skill of the craftsman who created it and the ingenuity with which he utilizes it.”
Craig D. Lounsbrough
The big danger is not just security vulnerabilities, but over-dependence on the tool, which I believe will lead to an eventual decline in the number of code craftsmen in the coming generation. How should newer and experienced developers go about this?
Here is a list of questions I ask myself when picking up AI in my development work:
Think about this: if we stop asking questions, how will AI be trained in the future? Technologies change and improve over time. What’s updated now will soon become old-fashioned. Take CSS, for example. With the recent CSS updates (nesting, view transitions, container queries, etc.), we are writing CSS vastly different than even a few short years ago. You wouldn’t want to be stuck with an outdated and clumsy solution trained from code written decades ago. If we stop asking questions and answering them, don’t you think that would make the LLMs lag behind? That’s just me speculating, but I think it’s easy to imagine that being the case.
We cannot deny Stack Overflow’s service over the years. It got us asking. It got us answering. It got us thinking. The question we should all ask ourselves is,Will LLMs do the same?
I’ll leave you with this quote from Stack Overflow co-founder Jeff Atwood:
Stack Overflow is you. This is the scary part, the great leap of faith that Stack Overflow is predicated on: trusting your fellow programmers. The programmers who choose to participate in Stack Overflow are the “secret sauce” that makes it work.
Stack Overflow: When We Stop Asking originally handwritten and published with love on CSS-Tricks. You should really get the newsletter as well.
With a high of F and a low of 44F. Currently, it's 55F and Mostly Cloudy outside. Current wind speeds: 5 from the Northeast Pollen...
