DEV Community: mfaysal dev

Python List Comprehension Examples Explained

mfaysal dev — Fri, 02 Oct 2026 10:52:13 +0000

A Python list comprehension builds a new list in one line by writing [expression for item in iterable], with an optional if at the end to filter items. It replaces the "make an empty list, loop, append" pattern. Below are the list comprehension examples I actually use, from the basic form to filtering, if/else, nested loops and the mistakes that tripped me up.

When I started learning Python, comprehensions looked like a puzzle. Once I learned to read them out loud, they became one of my favourite parts of the language. Every example here was run with Python 3.13, and the output in the comments at the bottom of each block is the real output.

The basic syntax: from a for loop to one line

Here is the same list of squares built two ways:

# The classic loop way
squares = []
for n in range(1, 6):
    squares.append(n * n)
print(squares)

# The same thing as a list comprehension
squares = [n * n for n in range(1, 6)]
print(squares)

# Output:
# [1, 4, 9, 16, 25]
# [1, 4, 9, 16, 25]

The comprehension has three parts inside square brackets:

The expression (n * n): what goes into the new list.
The for clause (for n in range(1, 6)): where the items come from.
An optional condition (if ...): which items to keep.

The trick that helped me is to read it in plain English: "give me n * n for every n in 1 to 5." The result is always a brand new list. The original iterable is not changed.

Filtering with if

Put an if after the for clause and only the items that pass the test make it into the new list. This is the comprehension I write most often, usually to clean data before using it.

marks = [72, 45, 88, 39, 91, 60, 33]

# Keep only the passing marks (40 or more)
passed = [m for m in marks if m >= 40]
print(passed)

# Clean up messy user input: strip spaces, drop empty strings
raw_tags = ["  python ", "", "html", "   ", " css"]
tags = [t.strip().lower() for t in raw_tags if t.strip()]
print(tags)

# Output:
# [72, 45, 88, 91, 60]
# ['python', 'html', 'css']

The second example does two jobs at once. The condition if t.strip() drops strings that are empty or only spaces, because an empty string counts as false. The expression t.strip().lower() then tidies up the ones that are left.

Using if/else in a list comprehension

This is the part that confused me the most. There are two different places a condition can go, and they do different things:

marks = [72, 45, 88, 39, 91]

# if/else goes BEFORE the for, because it decides the value
results = ["pass" if m >= 40 else "fail" for m in marks]
print(results)

# A filter goes AFTER the for, because it decides whether to keep the item
high = [m for m in marks if m >= 80]
print(high)

# Output:
# ['pass', 'pass', 'pass', 'fail', 'pass']
# [88, 91]

x if condition else y before the for is a conditional expression. It runs for every item and decides what value goes in. The new list is always the same length as the original.
if condition after the for is a filter. It decides whether an item goes in at all, so the new list can be shorter.

If you write [m for m in marks if m >= 40 else 0], Python raises a SyntaxError, because a filter can't have an else. Move the whole if/else to the front instead.

List comprehension examples with real data

Practice lists of numbers are fine, but most of the time I'm working with a list of dictionaries, such as rows from a CSV file or a JSON response from an API. Comprehensions are great for pulling out exactly the fields you need.

students = [
    {"name": "Rafi", "mark": 72},
    {"name": "Nusrat", "mark": 88},
    {"name": "Tanvir", "mark": 39},
]

names = [s["name"] for s in students]
print(names)

toppers = [s["name"] for s in students if s["mark"] >= 70]
print(toppers)

# Pair two lists together with zip()
subjects = ["Math", "Physics", "Chemistry"]
scores = [81, 67, 74]
report = [f"{sub}: {score}" for sub, score in zip(subjects, scores)]
print(report)

# Output:
# ['Rafi', 'Nusrat', 'Tanvir']
# ['Rafi', 'Nusrat']
# ['Math: 81', 'Physics: 67', 'Chemistry: 74']

The zip() example shows that the for clause can unpack values, just like a normal loop. for sub, score in zip(subjects, scores) walks through both lists side by side. Mixing in an f-string in the expression is a common way to build labels or lines of a report.

Nested list comprehensions

You can use more than one for in a comprehension, and you can put a comprehension inside another one. These are powerful, but they are also where readability goes downhill fast.

grid = [[1, 2, 3], [4, 5, 6], [7, 8, 9]]

# Flatten: read the for clauses left to right, like nested loops
flat = [n for row in grid for n in row]
print(flat)

# Build a 3x4 table of zeros (a list of lists)
table = [[0 for col in range(4)] for row in range(3)]
print(table)

# Transpose rows into columns
columns = [[row[i] for row in grid] for i in range(3)]
print(columns)

# Output:
# [1, 2, 3, 4, 5, 6, 7, 8, 9]
# [[0, 0, 0, 0], [0, 0, 0, 0], [0, 0, 0, 0]]
# [[1, 4, 7], [2, 5, 8], [3, 6, 9]]

For the flatten example, read the for clauses in the same order you would write nested loops: first for row in grid, then for n in row. The table and columns examples are different: there the inner comprehension is the expression, so each item of the outer list is itself a new list.

My rule: if I need more than two for clauses, or a nested comprehension plus a condition, I write a normal loop. Code is read more often than it is written.

Dict comprehensions, set comprehensions and generator expressions

The same syntax works with other brackets. Curly braces with a key: value pair give you a dictionary, and curly braces with a single value give you a set. Round brackets give you a generator expression, which produces values one at a time instead of building a whole list in memory.

words = ["apple", "banana", "avocado", "cherry", "apple"]

# Dict comprehension: word -> length
lengths = {w: len(w) for w in words}
print(lengths)

# Set comprehension: unique first letters
first_letters = {w[0] for w in words}
print(sorted(first_letters))

# Generator expression: no list is built, sum() pulls values one by one
total_chars = sum(len(w) for w in words)
print(total_chars)

# Output:
# {'apple': 5, 'banana': 6, 'avocado': 7, 'cherry': 6}
# ['a', 'b', 'c']
# 29

Notice that "apple" appears twice in the input but only once in the dictionary, because a later key overwrites an earlier one. I sorted the set before printing, since sets have no guaranteed order. When you only need to pass the values into a function like sum(), max(), any() or "".join(), a generator expression is enough, and you can drop the extra brackets.

Bonus: the walrus operator inside a comprehension

Sometimes the filter and the expression need the same calculated value. Since Python 3.8, the assignment expression := lets you compute it once and reuse it:

readings = ["12", "x", "7", "", "30"]

def to_int(text):
    try:
        return int(text)
    except ValueError:
        return None

# := stores the converted value so to_int() runs only once per item
numbers = [n for r in readings if (n := to_int(r)) is not None]
print(numbers)

# Output:
# [12, 7, 30]

Without :=, you would call to_int() twice per item, once in the filter and once in the expression. It's a handy tool, but use it lightly, because it makes the line harder to read for beginners.

Common mistakes with list comprehensions

1. Putting else in the wrong place

As covered above, if alone goes at the end, while if ... else ... goes at the front. When you get a SyntaxError in a comprehension, check this first.

2. Using a comprehension only for its side effects

A comprehension is for building a list. If you only want to do something for each item, like printing or saving to a file, use a normal loop:

names = ["rafi", "nusrat"]

# Don't do this: a list of None values built only for the side effect
result = [print(n.title()) for n in names]
print(result)

# Do this instead
for n in names:
    print(n.title())

# Output:
# Rafi
# Nusrat
# [None, None]
# Rafi
# Nusrat

The first version works, but it also builds a useless list of None values, because print() returns None. Anyone reading it will wonder what result is for.

3. Expecting the loop variable to exist afterwards

In Python 3, a comprehension has its own scope, so its loop variable does not overwrite a variable with the same name outside it:

x = "outer"
values = [x for x in range(3)]
print(values)
print(x)  # the loop variable does not leak out in Python 3

# Output:
# [0, 1, 2]
# outer

This is a good thing, but it means you can't use the loop variable after the comprehension ends, the way you can after a normal for loop.

4. Cramming too much into one line

A comprehension that runs past the edge of the screen, with function calls, conditions and nested loops, is not clever. It's just hard to debug. Split long comprehensions over several lines inside the brackets, or switch to a loop.

5. Building a big list you don't need

sum([x * x for x in range(1_000_000)]) creates a million-item list first. sum(x * x for x in range(1_000_000)) gives the same answer without storing the list.

FAQ

Are list comprehensions faster than for loops?

For simple cases they are usually a bit faster than a loop that calls append(), because there is less work per item. The difference is rarely what matters, though. Choose a comprehension because it's clearer for building a list, not to save microseconds.

Can I use elif in a list comprehension?

There is no elif keyword inside a comprehension, but you can chain conditional expressions: ["A" if m >= 80 else "B" if m >= 60 else "C" for m in marks]. It works, but past two conditions I move the logic into a small function and call that function in the expression.

What's the difference between a list comprehension and map()?

map(func, items) applies a function to every item and returns a lazy iterator. A list comprehension does the same job and can filter at the same time, and many Python developers find it easier to read. Both are fine. I mostly use comprehensions.

Do list comprehensions work with strings and files?

Yes. Any iterable works: strings give you characters, range() gives you numbers, and an open file gives you lines, so [line.strip() for line in f] is a common way to read a file into a clean list.

Conclusion

A list comprehension is a short way to say "build a new list from this iterable, transform each item, and optionally skip some". Start with the basic form, add a filter at the end when you need one, and remember that if/else goes at the front. When a comprehension gets hard to read, a plain loop is always allowed.

The official Python tutorial has a good section on list comprehensions with more examples if you want to go deeper. I'm still learning too, and you can see what I've been building on my projects page.

Originally published at mfaysal.com.

Python f-Strings: Formatting Examples

mfaysal dev — Fri, 02 Oct 2026 10:52:13 +0000

To format a string in Python, put an f before the quotes and write any variable or expression inside curly braces, like f"Hello {name}". Add a colon and a format spec to control how the value looks, for example f"{price:.2f}" for two decimal places. This guide collects the f-string formatting examples I reach for most: numbers, alignment, dates, debugging and the newer features in Python 3.12 and 3.14.

Before f-strings, I was gluing strings together with + and str(), which got messy quickly. F-strings fixed that. Every example below was run with Python 3.13 (or 3.14 where noted), and the comments at the bottom of each block show the real output.

F-string basics

An f-string (formatted string literal) is a normal string with an f or F prefix. Anything inside {} is evaluated as a Python expression when the line runs, and the result is turned into text.

name = "Mahir"
lessons_done = 7
total = 20

print(f"Hi {name}, you have finished {lessons_done} of {total} lessons.")
print(f"That leaves {total - lessons_done} to go.")
print(f"Your name in capitals is {name.upper()}.")

# Output:
# Hi Mahir, you have finished 7 of 20 lessons.
# That leaves 13 to go.
# Your name in capitals is MAHIR.

You're not limited to variable names. Arithmetic, method calls and function calls all work inside the braces. Keep them short, though. If the expression needs a comment to explain it, calculate it on the line above and put the variable in the f-string.

Formatting numbers with f-strings

The part after the colon is called the format specification. It uses the same "mini-language" as str.format(). These are the number formats I use all the time:

price = 1249.5
ratio = 0.4567
count = 42
views = 1234567

print(f"{price:.2f}")        # 2 decimal places
print(f"{price:,.2f}")       # thousands separator + 2 decimals
print(f"{ratio:.1%}")        # percentage with 1 decimal
print(f"{count:05d}")        # pad with zeros to width 5
print(f"{views:,}")     # comma groups
print(f"{views:_}")     # underscore groups
print(f"{count:b} {count:x} {count:#x}")  # binary, hex, hex with prefix

# Output:
# 1249.50
# 1,249.50
# 45.7%
# 00042
# 1,234,567
# 1_234_567
# 101010 2a 0x2a

.2f means "fixed-point with 2 digits after the decimal point". It rounds, it doesn't just cut off.
, or _ adds a separator every three digits. It goes before the precision: ,.2f, not .2f,.
% multiplies by 100 and adds a percent sign, so store ratios like 0.4567, not 45.67.
05d pads an integer with zeros to a width of 5, which is handy for IDs and file names like img_00042.png.
b, o and x show binary, octal and hex. Add # to include the 0b, 0o or 0x prefix.

Aligning text and building simple tables

When I print results in the terminal, alignment makes them much easier to read. Use < for left, > for right and ^ for centre, followed by a width. You can put a fill character before the alignment symbol.

rows = [("Python", 92), ("HTML", 85), ("JavaScript", 7)]

print(f"{'Subject':<12}|{'Score':>6}")
print("-" * 19)
for subject, score in rows:
    print(f"{subject:<12}|{score:>6}")

print(f"[{'hi':^10}]")    # centre in 10 characters
print(f"[{'hi':*^10}]")   # centre with * as the fill

# Output:
# Subject     | Score
# -------------------
# Python      |    92
# HTML        |    85
# JavaScript  |     7
# [    hi    ]
# [****hi****]

Strings are left-aligned by default and numbers are right-aligned by default, but I write the alignment out anyway so the intent is obvious. Notice the single quotes inside the double-quoted f-string, like {'Subject':<12}. That works in every Python version that has f-strings.

The = specifier for quick debugging

This is my favourite f-string feature. Put = after an expression and Python prints the expression text, an equals sign and the value. It's much faster than typing labels by hand when you're tracking down a bug.

width = 1200
height = 630
title = "Flexbox vs Grid"

print(f"{width=}, {height=}")
print(f"{width / height = :.2f}")
print(f"{title!r}")
print(f"{title=}")

# Output:
# width=1200, height=630
# width / height = 1.90
# 'Flexbox vs Grid'
# title='Flexbox vs Grid'

A few details worth knowing:

Spaces around the = are kept in the output, so {width / height = } prints with spaces.
You can still add a format spec after it: {width / height = :.2f}.
With =, Python uses repr() by default (unless you add a format spec), which is why strings show up with quotes. !r does the same thing on its own, and !s forces str().

Formatting dates and times

date and datetime objects accept strftime codes directly in the format spec, so you don't need to call .strftime() yourself.

from datetime import date, datetime

exam = date(2026, 11, 15)
start = datetime(2026, 10, 2, 15, 20)

print(f"Exam day: {exam:%d %B %Y}")
print(f"Weekday: {exam:%A}")
print(f"Started at {start:%H:%M} on {start:%Y-%m-%d}")
print(f"ISO format: {exam.isoformat()}")

# Output:
# Exam day: 15 November 2026
# Weekday: Sunday
# Started at 15:20 on 2026-10-02
# ISO format: 2026-11-15

The codes I use most are %d (day), %m (month number), %B (full month name), %Y (four-digit year), %A (weekday), and %H:%M (24-hour time). Month and day names depend on the system locale, so they may not be in English everywhere.

Dynamic widths and precision

The format spec can contain its own braces. This lets you choose the precision or width at runtime, which is useful when the user picks how many decimal places to show.

value = 3.14159265
for digits in (1, 3, 5):
    print(f"{value:.{digits}f}")

width = 8
print(f"[{'end':>{width}}]")

# Output:
# 3.1
# 3.142
# 3.14159
# [     end]

Newer f-string features (Python 3.12 and 3.14)

Reusing the same quotes (Python 3.12+)

Since Python 3.12, f-strings are parsed properly by the language grammar (PEP 701). You can reuse the same quote type inside the braces, use backslashes inside expressions and split long expressions over several lines.

# Works on Python 3.12 and newer (PEP 701)
user = {"name": "Nusrat", "city": "Dhaka"}
print(f"{user["name"]} lives in {user["city"]}")

lines = ["first", "second"]
print(f"{'\n'.join(lines)}")

# Output:
# Nusrat lives in Dhaka
# first
# second

On Python 3.11 and older, each of those lines is a SyntaxError. If your code has to run on an older server, stick to switching between single and double quotes.

T-strings: template strings (Python 3.14+)

Python 3.14 added t-strings (PEP 750). They look like f-strings with a t prefix, but instead of returning a finished str, they return a Template object that keeps the static text and the values separate:

# Python 3.14+ only: t-strings return a Template, not a str
from string.templatelib import Template

name = "<b>Rafi</b>"
greeting = t"Hello {name}"
print(type(greeting).__name__)
print(greeting.strings)
print(greeting.interpolations[0].value)

# Output:
# Template
# ('Hello ', '')
# <b>Rafi</b>

That separation means a library can escape the values before joining them, for example to make HTML or SQL safer. For everyday printing and messages, f-strings are still the tool to use.

Common mistakes with f-strings

1. Forgetting the f

Without the prefix, Python doesn't complain. It just prints the braces literally:

name = "Mahir"
print("Hello {name}")   # forgot the f
print(f"Hello {name}")

# Output:
# Hello {name}
# Hello Mahir

2. Needing a literal curly brace

To print { or } in an f-string, double it. I hit this whenever I generate CSS or JSON-like text:

selector = "body"
print(f"{selector} {{ margin: 0; }}")

# Output:
# body { margin: 0; }

3. Expecting perfect rounding from floats

Floats are stored in binary, so some decimals can't be stored exactly. 2.675 is really a tiny bit less than 2.675, so it rounds down:

total = 2.675
print(f"{total:.2f}")      # floats can't store 2.675 exactly
from decimal import Decimal
print(f"{Decimal('2.675'):.2f}")

# Output:
# 2.67
# 2.68

For money or anything where exact decimals matter, use Decimal, and create it from a string, not a float.

4. Building SQL queries with f-strings

Never put user input into an SQL query with an f-string. That's how SQL injection happens: the input can close your quote and add its own SQL. Use your database library's placeholders instead. Here's a quick test with the built-in sqlite3 module:

import sqlite3

conn = sqlite3.connect(":memory:")
conn.execute("CREATE TABLE users (email TEXT, name TEXT)")
conn.execute("INSERT INTO users VALUES (?, ?)", ("rafi@example.com", "Rafi"))

email = "rafi@example.com' OR '1'='1"   # a malicious input

# Unsafe: f"SELECT name FROM users WHERE email = '{email}'" would return every row
rows = conn.execute("SELECT name FROM users WHERE email = ?", (email,)).fetchall()
print(rows)   # the placeholder treats the whole input as one plain value

# Output:
# []

With an f-string, that same input turns the WHERE clause into something that's always true, and the query returns Rafi's row even though the email doesn't match. With the ? placeholder, the database treats the whole input as plain data, so nothing matches. The same idea applies in every language. I wrote about the PHP version with PDO prepared statements in another tip.

5. Using f-strings in logging calls

With the logging module, the usual advice is logging.debug("User %s logged in", name) rather than an f-string. Logging only builds the message if that level is actually enabled, while an f-string is always built first.

FAQ

Which Python version do I need for f-strings?

F-strings have been in Python since 3.6. The = debugging specifier needs 3.8 or newer, reusing quotes inside braces needs 3.12, and t-strings need 3.14.

Are f-strings faster than format() and %?

In general, yes: f-strings are usually at least as fast as str.format() and % formatting. I pick them mainly because they're easier to read, since the value sits right where it appears in the text.

How do I write a multi-line f-string?

Use triple quotes with the f prefix: f"""...""". Every line can contain replacement fields. You can also put several f-strings next to each other inside parentheses, and Python joins them into one string.

Can I use a dictionary value inside an f-string?

Yes. On Python 3.12+ you can write f"{user["name"]}". On older versions, use the other quote type: f"{user['name']}".

Conclusion

F-strings put the value right where it appears in the text, and the format spec after the colon controls how it looks: .2f for decimals, , for thousands, % for percentages, < ^ > for alignment, and date codes for dates. Add = when debugging, and you'll rarely need anything else.

For the full list of options, the Python docs have a page on the format specification mini-language. If you want to see what I'm building while learning, have a look at my projects.

Originally published at mfaysal.com.

HTML Semantic Tags Explained With Examples

mfaysal dev — Fri, 02 Oct 2026 10:52:11 +0000

HTML semantic tags are elements whose names describe what their content is, not how it looks. <header>, <nav>, <main>, <article>, <section>, <aside> and <footer> tell browsers, screen readers and search engines what each part of the page is for, while a <div> tells them nothing. In this post I explain each semantic tag with examples, show how I structure a real page, and list the mistakes I made when I first started using them.

When I built my first websites, every box was a <div> with a class name. The pages looked fine, but the HTML didn't describe anything. Switching to semantic tags didn't change how my pages looked at all. It changed how well they worked for everyone who can't just look at the screen.

What "semantic" means in HTML

Here's a typical "div soup" layout, the kind I used to write:

<div class="header">
  <div class="logo">My Blog</div>
  <div class="menu">
    <div class="link"><a href="/">Home</a></div>
    <div class="link"><a href="/blog">Blog</a></div>
  </div>
</div>
<div class="content">
  <div class="post">
    <div class="title">My first post</div>
    <div class="text">Hello!</div>
  </div>
</div>
<div class="footer">© 2026</div>

It's valid HTML, but a screen reader has no idea which part is the navigation and which part is the main content. The class names header and menu mean something to me, not to the browser.

Now the same page with semantic tags:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>My Blog</title>
</head>
<body>
  <header>
    <a href="/">My Blog</a>
    <nav aria-label="Main">
      <ul>
        <li><a href="/">Home</a></li>
        <li><a href="/blog">Blog</a></li>
        <li><a href="/projects">Projects</a></li>
      </ul>
    </nav>
  </header>

  <main>
    <article>
      <h1>My first post</h1>
      <p>Hello!</p>
    </article>

    <aside aria-label="About the author">
      <h2>About me</h2>
      <p>Student web developer from Bangladesh.</p>
    </aside>
  </main>

  <footer>
    <p>© 2026 My Blog</p>
  </footer>
</body>
</html>

Same content, but now the structure is built into the HTML. Screen reader users can jump straight to the navigation or the main content, because these elements map to landmarks. Search engines get clearer signals about which text is the actual article. And when I come back to the code a month later, I can see the layout at a glance.

The main semantic tags explained

Introductory content, usually a logo, site title, navigation or a search form. A page can have more than one: one at the top of the page and one inside each <article> for its title and date. When a <header> isn't inside an article, section or similar element, it becomes the page's banner landmark.

A block of major navigation links, like the main menu, a table of contents or pagination. Not every group of links needs a <nav>. A couple of links in the footer are usually fine without one. If you have more than one <nav>, give each an aria-label (like "Main" or "Footer") so screen reader users can tell them apart.

The main content of the page, the part that's unique to it. There should be only one visible <main> per page, and it shouldn't be inside <header>, <footer>, <nav>, <article> or <aside>. Repeated things like the site header and footer stay outside it.

A self-contained piece of content that would still make sense on its own, such as a blog post, a news story, a product card or a comment. A good test: could you share it or put it in an RSS feed by itself? If yes, it's probably an article.

A thematic group of content, normally with its own heading. Think chapters of a post or the "Features" and "Pricing" parts of a landing page. If you only need a wrapper for styling or layout, use a <div>. A <section> without a heading is often a sign you wanted a div.

Content that's related to the content around it but not part of its main flow: a sidebar, an author box, a "related posts" list or a pull quote.

Information about its section or page: copyright, author, related links, contact details. Like <header>, it can be used for the whole page or inside an article.

A blog post marked up with semantic tags

Here's how I'd mark up a single blog post. It uses an article-level header and footer, sections for the main parts, <time> for the date and <figure> for an image with a caption:

<article>
  <header>
    <h2>CSS Flexbox vs Grid</h2>
    <p>Published <time datetime="2026-10-02">2 October 2026</time></p>
  </header>

  <section>
    <h3>When to use Flexbox</h3>
    <p>Flexbox lays items out in one direction.</p>
  </section>

  <section>
    <h3>When to use Grid</h3>
    <p>Grid handles rows and columns together.</p>
  </section>

  <figure>
    <img src="layout-diagram.png" alt="Flexbox row next to a two-dimensional grid" width="800" height="400">
    <figcaption>Flexbox works in one dimension, Grid in two.</figcaption>
  </figure>

  <footer>
    <p>Tags: <a href="/tag/css">CSS</a></p>
  </footer>
</article>

<time datetime="..."> gives machines an exact date in a standard format, while the visible text can be written however you like.
<figure> with <figcaption> connects an image, chart or code sample to its caption. The alt text still matters: the caption is for everyone, the alt text replaces the image for people who can't see it.
Headings still do the real work. The old idea that each <section> resets heading levels (the "document outline algorithm") was never implemented by browsers and has been removed from the HTML spec. Use <h1> to <h6> in a logical order yourself.

Smaller semantic tags worth knowing

Semantics isn't only about page layout. Inline elements carry meaning too:

<p><strong>Warning:</strong> this deletes every note.</p>
<p>I <em>really</em> mean every note.</p>
<p>Press <kbd>Ctrl</kbd> + <kbd>S</kbd> to save.</p>
<p>Run <code>npm install</code> first.</p>
<p>The exam is on <time datetime="2026-11-15">15 November</time>.</p>
<p><mark>Highlighted</mark> text and an <abbr title="HyperText Markup Language">HTML</abbr> abbreviation.</p>
<address>Contact: <a href="mailto:hello@example.com">hello@example.com</a></address>

<strong> means strong importance, and <em> means stress emphasis that changes how a sentence reads. <b> and <i> still exist, for text that's styled differently without being more important, like a term or a ship name.
<kbd> is for keyboard input, <code> for code, <mark> for highlighted text and <abbr> for abbreviations.
<address> is for contact information for the nearest article or the page. It's not meant for every postal address that appears in your text.

Two more I use often are <details> and <summary>, which give you an accessible open/close widget without any JavaScript:

<details>
  <summary>What is a semantic tag?</summary>
  <p>A tag whose name describes the meaning of its content.</p>
</details>

And there's a newer one, <search>, for wrapping a search form. It gives the form a search landmark without needing role="search", and it's supported in current versions of the major browsers:

<search>
  <form action="/search">
    <label for="q">Search posts</label>
    <input id="q" name="q" type="search">
    <button type="submit">Search</button>
  </form>
</search>

Common mistakes with semantic HTML

1. Using a div as a button

This is the most harmful one, and I've done it:

<!-- Avoid: not focusable, no keyboard support, not announced as a button -->
<div class="btn" onclick="saveNote()">Save</div>

<!-- Better: works with Tab, Enter and Space out of the box -->
<button type="button" onclick="saveNote()">Save</button>

A <div> with a click handler can't be reached with the Tab key, doesn't respond to Enter or Space, and isn't announced as a button. A real <button> does all of that for free. Use <a href> for things that go somewhere and <button> for things that do something.

2. Using section as a generic wrapper

Replacing every div with <section> doesn't make a page more semantic. If there's no heading and no real theme, it should stay a div.

3. Picking headings by size

Choosing <h4> because it looks the right size breaks the heading structure that screen reader users navigate by. Pick the level that matches the structure, then change the size with CSS.

4. More than one main, or main inside article

Keep one visible <main> per page, as a direct part of the body layout, not nested inside other landmarks.

5. Thinking semantic tags add styles

Most of these elements look exactly like a div by default. Semantics is about meaning. You still write the CSS.

FAQ

Do semantic HTML tags help SEO?

They help search engines understand your page structure and find the main content, and they make the page more accessible, which is good practice anyway. They're not a magic ranking boost on their own. Useful content and a clear heading structure matter more.

What's the difference between article and section?

An <article> makes sense on its own, like a full blog post. A <section> is one part of something bigger, like one chapter of that post. Articles can contain sections, and a section can contain several articles, like a list of post cards.

Should I stop using div completely?

No. <div> is the right choice when you need a container for styling or layout and no semantic element fits. The goal is to use meaningful tags where they exist, not to ban divs.

Can I have more than one header and footer on a page?

Yes. You can have a page-level header and footer, plus a header and footer inside each article or section.

Conclusion

Semantic HTML means picking the element that describes your content: <header> and <footer> for intro and closing info, <nav> for major links, one <main> for the unique content, <article> for things that stand alone, <section> for themed parts with headings, and <aside> for related extras. Use real buttons and real headings, and keep <div> for pure layout.

MDN's HTML elements reference is where I check what each element is for. If you want to see what I build with it, my projects page has the list.

Originally published at mfaysal.com.

JavaScript Async/Await Tutorial for Beginners

mfaysal dev — Fri, 02 Oct 2026 10:52:10 +0000

Async/await is a cleaner way to work with promises in JavaScript. Mark a function with async, then put await in front of a promise to pause that function until the promise settles, and use try/catch to handle errors. Your asynchronous code ends up reading top to bottom like normal code. In this async/await tutorial I start from the basics and work up to running tasks in parallel, using fetch safely, retrying and the mistakes I made along the way.

All examples are ES modules (.mjs files) that I ran with Node.js 20, and the comments at the end of each block show the real output. They work the same way in modern browsers, apart from the bits that rely on top-level await, which needs a module script.

Why async/await exists

JavaScript runs your code on a single thread. If it stopped and waited every time it asked a server for data, the whole page would freeze. So slow operations like network requests and timers are asynchronous: they start now and finish later, and a promise represents that future result.

Before async/await, you handled promises with chains of .then() calls, and before promises, with nested callbacks. Both work, but long chains get hard to follow. Async/await is built on top of promises, so it isn't a different system, just a nicer syntax for the same thing.

Your first async function

// A promise that resolves after `ms` milliseconds
function wait(ms) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

async function greet(name) {
  await wait(500); // pause this function, not the whole program
  return `Hello, ${name}!`;
}

console.log("1. before");
greet("Mahir").then((message) => console.log("3.", message));
console.log("2. after (greet is still waiting)");

// Output:
// 1. before
// 2. after (greet is still waiting)
// 3. Hello, Mahir!

Look at the order of the output. await pauses only greet. The rest of the program keeps running, which is why "2. after" prints before the greeting arrives. This is the most important idea in the whole tutorial: await doesn't block JavaScript, it pauses the current async function.

An async function always returns a promise

async function getNumber() {
  return 42;
}

const result = getNumber();
console.log(result instanceof Promise); // an async function always returns a promise
console.log(await result);              // await unwraps it (top-level await in a module)

// Output:
// true
// 42

Even though getNumber returns a plain 42, calling it gives you a promise. To get the value, you await it (or use .then()). Inside an ES module you can use await at the top level like this; in a regular script, await only works inside an async function.

Handling errors with try/catch

When an awaited promise rejects, await throws the error, so you catch it with an ordinary try/catch. finally runs either way, which makes it a good place to hide a loading spinner.

function loadProfile(id) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      if (id === 1) resolve({ id, name: "Nusrat" });
      else reject(new Error(`No profile with id ${id}`));
    }, 200);
  });
}

async function showProfile(id) {
  try {
    const profile = await loadProfile(id);
    console.log("Loaded:", profile.name);
  } catch (error) {
    console.log("Failed:", error.message);
  } finally {
    console.log("Done with id", id);
  }
}

await showProfile(1);
await showProfile(2);

// Output:
// Loaded: Nusrat
// Done with id 1
// Failed: No profile with id 2
// Done with id 2

Using fetch with async/await

The most common real use of async/await is loading data with fetch. Here's the pattern I use, tested against the free JSONPlaceholder API:

async function getUser(id) {
  const response = await fetch(`https://jsonplaceholder.typicode.com/users/${id}`, {
    signal: AbortSignal.timeout(5000), // give up after 5 seconds
  });

  // fetch only rejects on network errors, so check the HTTP status yourself
  if (!response.ok) {
    throw new Error(`HTTP ${response.status}`);
  }

  return response.json(); // also returns a promise
}

try {
  const user = await getUser(1);
  console.log(user.name, "-", user.email);
  await getUser(9999); // this user does not exist
} catch (error) {
  console.log("Request failed:", error.message);
}

// Output:
// Leanne Graham - Sincere@april.biz
// Request failed: HTTP 404

Two details catch almost everyone out:

fetch doesn't reject on HTTP errors. A 404 or 500 response still resolves. It only rejects if the request couldn't be made at all. That's why I check response.ok and throw my own error.
response.json() is asynchronous too. Reading the body takes time, so it returns another promise. Returning it from an async function is fine, because the caller's await unwraps it.

AbortSignal.timeout(5000) cancels the request if it takes longer than five seconds, so a hanging server can't leave your page waiting forever. It works in current browsers and in Node 18+.

In my Quizwright project, the page sends its form data to a single server route with a plain fetch, and the server does the AI call so the API key never reaches the browser. I wrote about that in how I kept my AI API key off the browser.

Sequential vs parallel: Promise.all

This is where async/await code often gets slower than it needs to be. Each await waits for the one before it. If two requests don't depend on each other, start them both, then wait for both:

const wait = (ms, value) =>
  new Promise((resolve) => setTimeout(() => resolve(value), ms));

const seconds = (start) => ((Date.now() - start) / 1000).toFixed(1);

// Sequential: each await waits for the previous one
let start = Date.now();
const a = await wait(1000, "posts");
const b = await wait(1000, "projects");
console.log("sequential:", a, b, "in", seconds(start), "s");

// Parallel: start both first, then wait for both
start = Date.now();
const [c, d] = await Promise.all([wait(1000, "posts"), wait(1000, "projects")]);
console.log("parallel:", c, d, "in", seconds(start), "s");

// Output:
// sequential: posts projects in 2.0 s
// parallel: posts projects in 1.0 s

Two one-second tasks took two seconds in sequence and one second in parallel. Promise.all takes an array of promises and resolves with an array of results, in the same order you passed them in, no matter which finishes first. If any of them rejects, Promise.all rejects straight away.

When some tasks are allowed to fail: Promise.allSettled

On a dashboard that loads several widgets, one broken API shouldn't blank the whole page. Promise.allSettled waits for everything and tells you how each one went:

const ok = (value) => Promise.resolve(value);
const fail = (message) => Promise.reject(new Error(message));

const results = await Promise.allSettled([
  ok("weather loaded"),
  fail("news API is down"),
  ok("quote loaded"),
]);

for (const r of results) {
  if (r.status === "fulfilled") console.log("✔", r.value);
  else console.log("✘", r.reason.message);
}

// Output:
// ✔ weather loaded
// ✘ news API is down
// ✔ quote loaded

There's also Promise.race (the first to settle wins) and Promise.any (the first to succeed wins), but all and allSettled are the ones I use most.

Retrying a failed request

Networks and APIs fail sometimes. A small retry helper with a growing delay handles short glitches:

const wait = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

async function withRetry(task, attempts = 3, delayMs = 300) {
  for (let i = 1; i <= attempts; i++) {
    try {
      return await task(i); // return await, so errors are caught here
    } catch (error) {
      console.log(`Attempt ${i} failed: ${error.message}`);
      if (i === attempts) throw error;
      await wait(delayMs * i); // wait a little longer each time
    }
  }
}

// A fake task that fails twice, then works
const flaky = async (attempt) => {
  if (attempt < 3) throw new Error("server busy");
  return "saved!";
};

console.log(await withRetry(flaky));

// Output:
// Attempt 1 failed: server busy
// Attempt 2 failed: server busy
// saved!

Notice return await task(i) inside the try. Without the await, a rejected promise would be returned straight to the caller and the catch block here would never run. Keep retries small. Retrying a request that failed because the input was invalid just wastes time.

Common mistakes with async/await

1. Using await inside forEach

forEach ignores the promises its callback returns, so it doesn't wait:

const wait = (ms) => new Promise((resolve) => setTimeout(resolve, ms));
const ids = [1, 2, 3];

// Wrong: forEach does not wait for async callbacks
ids.forEach(async (id) => {
  await wait(100);
  console.log("forEach finished", id);
});
console.log("forEach returned already");

await wait(200); // let the forEach callbacks finish before the next demo

// Right: for...of waits for each one in order
for (const id of ids) {
  await wait(100);
  console.log("for...of finished", id);
}
console.log("for...of is really done");

// Output:
// forEach returned already
// forEach finished 1
// forEach finished 2
// forEach finished 3
// for...of finished 1
// for...of finished 2
// for...of finished 3
// for...of is really done

"forEach returned already" prints first, before any callback has finished. Use for...of when tasks must run one after another, or await Promise.all(ids.map(async (id) => { ... })) when they can run in parallel.

2. Forgetting to handle rejections

If you call an async function that throws and never await it or attach .catch(), you get an unhandled rejection. In Node.js, that crashes the process by default. I checked: calling save() without handling it ended the script with exit code 1.

async function save() {
  throw new Error("disk full");
}

// Missing await/catch: in Node this crashes the process with an unhandled rejection.
// save();

// Handle it with try/catch around await...
try {
  await save();
} catch (e) {
  console.log("caught with try/catch:", e.message);
}

// ...or with .catch() when you don't await
save().catch((e) => console.log("caught with .catch():", e.message));

// Output:
// caught with try/catch: disk full
// caught with .catch(): disk full

3. Forgetting await

Without await, you get the promise, not the value. If you see Promise { <pending> } in the console or [object Promise] on the page, a missing await is almost always the reason.

4. Awaiting independent tasks one by one

As the timing example showed, back-to-back awaits add up. If the second request doesn't need the result of the first, use Promise.all.

5. Not checking response.ok

Without that check, your code happily tries to read an error page as data, and the real problem shows up later as a confusing error somewhere else.

FAQ

Is async/await better than .then()?

They do the same thing, because async/await is built on promises. I find async/await easier to read, especially with error handling and loops, but .then() is still fine for short one-off chains, and you can mix the two.

Does await block the main thread?

No. It pauses only the async function it's in. Other code, event handlers and rendering keep running while it waits.

Can I use await outside an async function?

Only at the top level of an ES module, like a .mjs file in Node or a <script type="module"> in the browser. Everywhere else it must be inside an async function.

How do I run async tasks with a limit, like 2 at a time?

Split the list into small batches and await Promise.all each batch inside a loop. It's simple, and it stops you from flooding a server with hundreds of requests at once:

const wait = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

async function upload(file) {
  await wait(100); // pretend this is a network request
  return `${file} uploaded`;
}

const files = ["a.png", "b.png", "c.png", "d.png", "e.png"];
const batchSize = 2;

for (let i = 0; i < files.length; i += batchSize) {
  const batch = files.slice(i, i + batchSize);
  const results = await Promise.all(batch.map(upload)); // 2 at a time
  console.log(results.join(", "));
}

// Output:
// a.png uploaded, b.png uploaded
// c.png uploaded, d.png uploaded
// e.png uploaded

Each batch waits for the slowest item in it, so a dedicated concurrency library is faster for big jobs, but for a handful of uploads this is all I need.

Conclusion

Async/await lets you write asynchronous JavaScript that reads like normal code: async on the function, await on the promise, try/catch for errors. Remember that await only pauses its own function, check response.ok after fetch, use Promise.all for independent tasks, and avoid await inside forEach.

For a deeper look at how promises work underneath, MDN's guide on how to use promises is excellent.

Originally published at mfaysal.com.

HTML Form Input Types and Validation

mfaysal dev — Fri, 02 Oct 2026 10:52:10 +0000

HTML gives you built-in form validation without any JavaScript: pick the right type on each <input> (like email, url, number or date) and add attributes such as required, minlength, maxlength, min, max, step and pattern. The browser then blocks submission and shows a message until the values fit. In this guide I go through the input types and validation attributes I use, with examples I checked in a current Chrome build, plus the gotchas that caught me out.

One thing to say right away: browser validation is there to help the user. It's not security. Anyone can turn it off or send a request without your form, so the server has to check everything again.

A sign-up form using HTML validation only

Here's a small, complete form. There's no JavaScript, but it already refuses empty names, short passwords, badly formed emails and ages outside the range:

<form action="/signup" method="post">
  <label for="name">Full name</label>
  <input id="name" name="name" type="text" autocomplete="name" required minlength="2" maxlength="60">

  <label for="email">Email</label>
  <input id="email" name="email" type="email" autocomplete="email" required>

  <label for="password">Password (at least 8 characters)</label>
  <input id="password" name="password" type="password" autocomplete="new-password" required minlength="8">

  <label for="age">Age</label>
  <input id="age" name="age" type="number" min="13" max="120" step="1">

  <button type="submit">Create account</button>
</form>

A few things are doing quiet work here:

Every input has a <label> linked with for and id. Clicking the label focuses the field, and screen readers read it out. A placeholder is not a replacement for a label, because it disappears as soon as you type.
name is what the server receives. An input without a name isn't sent at all.
autocomplete values like email, name and new-password let browsers and password managers fill the form correctly.

HTML input types and what they give you

Choosing the right type gives you three things: a validation rule, a better keyboard on phones and sometimes a native picker.

<label for="site">Website</label>
<input id="site" name="site" type="url" placeholder="https://example.com">

<label for="phone">Phone</label>
<input id="phone" name="phone" type="tel" autocomplete="tel">

<label for="exam">Exam date</label>
<input id="exam" name="exam" type="date" min="2026-01-01" max="2026-12-31">

<label for="start">Start time</label>
<input id="start" name="start" type="time" step="900">

<label for="hours">Study hours per day</label>
<input id="hours" name="hours" type="range" min="0" max="12" step="0.5" value="3">

<label for="accent">Accent colour</label>
<input id="accent" name="accent" type="color" value="#8b7cff">

<label for="q">Search notes</label>
<input id="q" name="q" type="search">

email checks the basic shape of an address. In my testing, abc was rejected with "Please include an '@'", but a@b was accepted, because the spec allows addresses without a dot (like on an intranet).
url needs a scheme. example.com fails; https://example.com passes.
tel doesn't validate anything by itself, because phone formats vary so much between countries. It mainly brings up a number pad on phones. Add a pattern if you need a format.
number works with min, max and step. With step="1", a value of 13.5 fails with a step error.
date and time show native pickers. The value is always sent in a fixed format (2026-11-15 for dates, 14:30 for times), no matter how it's displayed to the user.
range always has a value, and it clamps to min/max. When I set it to 13 with max="12", the value became 12.
color opens a colour picker and sends a hex value like #8b7cff.
search behaves like text but may show a clear button and fits nicely inside a <search> element.

The validation attributes

required

The field must have a value. For a group of radio buttons with the same name, putting required on one of them makes the whole group required. On a checkbox, it means "must be ticked", which is what you want for "I agree to the terms".

minlength and maxlength

Limits on the number of characters for text-like inputs. maxlength stops the user from typing more. minlength is checked when the user has edited the field. One thing I found while testing: setting a too-short value from JavaScript didn't count as invalid, because the browser only applies minlength to values the user typed.

min, max and step

For number, range and the date and time types. Dates use the same format as the value: min="2026-01-01". For time, step is in seconds, so step="900" means 15-minute steps.

pattern

A regular expression the whole value must match. You don't need ^ and $, because the pattern is always matched against the entire value.

<label for="username">Username</label>
<input id="username" name="username" type="text"
       required pattern="[a-z0-9_]{3,16}"
       title="3 to 16 characters: lowercase letters, numbers and underscores">

<label for="mobile">Mobile number (11 digits, starting with 01)</label>
<input id="mobile" name="mobile" type="tel" inputmode="numeric"
       pattern="01[0-9]{9}" autocomplete="tel">

The title text is shown as a hint alongside the browser's "Please match the requested format" message in many browsers, so use it to explain the rule in plain words. In my test, mahir_01 passed, while Ab and abc! failed. The mobile pattern accepted 01712345678 and rejected 0171.

Radio buttons, checkboxes and suggestions

<fieldset>
  <legend>Preferred language</legend>
  <input id="lang-py" type="radio" name="lang" value="python" required>
  <label for="lang-py">Python</label>
  <input id="lang-js" type="radio" name="lang" value="javascript">
  <label for="lang-js">JavaScript</label>
</fieldset>

<label for="city">City</label>
<input id="city" name="city" type="text" list="cities">
<datalist id="cities">
  <option value="Dhaka"></option>
  <option value="Chattogram"></option>
  <option value="Sylhet"></option>
</datalist>

<input id="terms" name="terms" type="checkbox" required>
<label for="terms">I agree to the terms</label>

<fieldset> and <legend> group related radio buttons and give the group a name that screen readers announce. <datalist> suggests values but still lets the user type anything. If only those values are allowed, use a <select> instead.

Styling valid and invalid fields

The old :invalid selector matches as soon as the page loads, so an empty required field shows up red before the user has done anything. The newer :user-invalid and :user-valid pseudo-classes only match after the user has interacted with the field, and they're supported in current major browsers:

input:user-invalid {
  border-color: #d93025;
  outline-color: #d93025;
}

input:user-valid {
  border-color: #188038;
}

Custom rules with a little JavaScript

Some rules can't be written as attributes, like "both passwords must match". The Constraint Validation API lets you plug your own rule into the same system with setCustomValidity():

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Confirm password</title>
</head>
<body>
  <form id="signup">
    <label for="pw">Password</label>
    <input id="pw" name="pw" type="password" required minlength="8">
    <label for="pw2">Confirm password</label>
    <input id="pw2" name="pw2" type="password" required>
    <button type="submit">Sign up</button>
  </form>
  <script>
    const pw = document.getElementById("pw");
    const pw2 = document.getElementById("pw2");

    function checkMatch() {
      if (pw2.value !== pw.value) {
        pw2.setCustomValidity("Passwords do not match.");
      } else {
        pw2.setCustomValidity(""); // empty string = valid again
      }
    }

    pw.addEventListener("input", checkMatch);
    pw2.addEventListener("input", checkMatch);
  </script>
</body>
</html>

A non-empty message marks the field invalid and blocks submission with your text. An empty string clears the error. I loaded this page in headless Chrome and set the values from a script: with different passwords, validity.customError was true, and once they matched the field was valid again.

Common mistakes with HTML form validation

1. Trusting it on the server

Client-side validation can be skipped with dev tools or a direct request. Always validate again on the server. In my Quizwright project, the server route checks every request against a strict schema before it does anything, which I explained in how I kept my AI API key off the browser.

2. Unescaped hyphens in pattern

Modern browsers compile pattern with the JavaScript v flag, which is stricter about character classes. In my test, pattern="[a-z0-9-]{3,}" was silently ignored, so even AB passed. Writing it as [a-z0-9\-]{3,} made the pattern work again. If a pattern seems to do nothing, check the console for a regex error.

3. Using placeholder as the label

Placeholders vanish while typing and often have low contrast. Keep a visible <label>.

4. Using type="number" for things that aren't numbers

Phone numbers, OTP codes and card numbers aren't quantities. number adds spinner arrows, accepts input like 1e5, and once the value is treated as a number, leading zeros are easy to lose. Use type="text" or tel with inputmode="numeric" and a pattern.

5. Forgetting the name attribute

The field validates perfectly and then never reaches the server.

FAQ

How do I turn off browser validation?

Add novalidate to the <form> to skip it for the whole form, or formnovalidate to a specific submit button, for example a "Save draft" button.

Can I change the default error message?

Yes, with setCustomValidity() in JavaScript, as in the password example. The title attribute adds a hint for pattern errors but doesn't replace the browser's message.

Is the email type enough to validate emails?

It catches typos like a missing @, but it accepts addresses like a@b. On the server, check the format again, and if the address really matters, send a confirmation email.

Do these attributes work on textarea and select?

required works on both, and minlength and maxlength work on <textarea>.

Conclusion

Start every form with the right input types and labels, then add required, length limits, min/max/step and pattern where they fit. Style errors with :user-invalid, use setCustomValidity() for rules that need code, and always validate again on the server.

MDN's guide to HTML form validation and the Constraint Validation API covers every attribute in detail and is worth bookmarking.

Originally published at mfaysal.com.

CSS Flexbox vs Grid: When to Use Each

mfaysal dev — Fri, 02 Oct 2026 10:52:08 +0000

The short answer to CSS Flexbox vs Grid: use Flexbox when you're lining things up in one direction, a row or a column, and want the content to decide the sizes. Use Grid when you need rows and columns at the same time, or when the layout should decide where things go. Most real pages use both: Grid for the overall layout and card lists, Flexbox for the small pieces inside them. Below I show how I decide, with code you can copy, plus the mistakes I made while learning both.

I used to pick one at random and fight it until the layout worked. Once I understood the "one dimension vs two dimensions" idea, choosing became easy. Every snippet here passes a CSS validator, and I rendered the layouts in headless Chrome to check they look the way I describe.

The core difference: one dimension vs two

Flexbox works along one main axis. Items flow in a line, and you control how they share the space, how they line up and whether they wrap. Wrapped lines don't line up with each other, though, because each line is laid out on its own.

Grid works on two axes at once. You define columns and rows on the container, and items are placed into that structure. Every item in a column lines up with the items above and below it.

Another way I think about it:

Flexbox is content-out. The size of the items drives the layout.
Grid is layout-in. You draw the structure first, then put items into it.

When to use Flexbox

Navigation bars and toolbars

A header with a logo on the left and links on the right is a single row, which is the perfect Flexbox job:

<header class="site-header">
  <a class="logo" href="/">mfaysal.dev</a>
  <nav aria-label="Main">
    <ul class="nav-links">
      <li><a href="/blog">Blog</a></li>
      <li><a href="/projects">Projects</a></li>
      <li><a href="/contact">Contact</a></li>
    </ul>
  </nav>
</header>

.site-header {
  display: flex;
  align-items: center;            /* vertical centring on the cross axis */
  justify-content: space-between; /* logo left, links right */
  gap: 1rem;
  padding: 1rem 1.5rem;
}

.nav-links {
  display: flex;
  flex-wrap: wrap;
  gap: 1.25rem;
  list-style: none;
  margin: 0;
  padding: 0;
}

justify-content controls spacing along the main axis (horizontal here), and align-items controls the cross axis (vertical here). gap adds space between items without margin hacks. It's been supported for Flexbox in all major browsers for years now.

One item takes the leftover space

A search input that stretches next to a fixed-size button is another classic Flexbox pattern:

<form class="search-bar" action="/search">
  <input name="q" type="search" placeholder="Search posts" aria-label="Search posts">
  <button type="submit">Search</button>
</form>

.search-bar {
  display: flex;
  gap: 0.5rem;
}

.search-bar input {
  flex: 1;        /* take all the leftover space */
  min-width: 0;   /* allow it to shrink below its default width */
}

flex: 1 tells the input to grow into whatever space is left. The min-width: 0 line fixes a very common bug: flex items won't shrink smaller than their content by default, so without it an input can overflow on small screens.

When to use CSS Grid

Responsive card grids without media queries

This is the Grid snippet I use most. It fits as many columns as there's room for, each at least 220px wide:

.card-grid {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(220px, 1fr));
  gap: 1.5rem;
}

<div class="card-grid">
  <article class="card">
    <h2>Quizwright</h2>
    <p>AI quiz generator.</p>
    <a href="/projects">View</a>
  </article>
  <article class="card">
    <h2>StudyPilot</h2>
    <p>Offline study planner with a longer description that wraps onto more lines.</p>
    <a href="/projects">View</a>
  </article>
  <article class="card">
    <h2>Kinetica</h2>
    <p>Canvas design and animation editor.</p>
    <a href="/projects">View</a>
  </article>
</div>

On a wide screen you get several columns; on a phone, one. No media queries needed. There's a small difference between the two keywords: auto-fill keeps empty column tracks when there are only a few cards, so they stay card-sized. auto-fit collapses the empty tracks, so the existing cards stretch to fill the row. I usually prefer auto-fill, because three cards stretched across a huge monitor look odd.

Whole-page layouts with grid-template-areas

For a header, sidebar, main content and footer, named areas make the CSS read almost like a picture of the layout:

<div class="page">
  <header>Header</header>
  <aside>Sidebar</aside>
  <main>Main content</main>
  <footer>Footer</footer>
</div>

.page {
  display: grid;
  grid-template-columns: 240px 1fr;
  grid-template-rows: auto 1fr auto;
  grid-template-areas:
    "header  header"
    "sidebar main"
    "footer  footer";
  min-height: 100vh;
  gap: 1rem;
}

.page > header { grid-area: header; }
.page > aside  { grid-area: sidebar; }
.page > main   { grid-area: main; }
.page > footer { grid-area: footer; }

@media (max-width: 700px) {
  .page {
    grid-template-columns: 1fr;
    grid-template-rows: auto 1fr auto auto;
    grid-template-areas:
      "header"
      "main"
      "sidebar"
      "footer";
  }
}

On small screens, the media query switches to one column and moves the sidebar below the main content just by changing the area map. The HTML order stays the same, which matters for keyboard and screen reader users.

Dashboards with items of different sizes

When some boxes should be wider or taller than others, Grid's span keyword is exactly right:

.dashboard {
  display: grid;
  grid-template-columns: repeat(4, 1fr);
  grid-auto-rows: 140px;
  gap: 1rem;
}

.widget--wide { grid-column: span 2; }
.widget--tall { grid-row: span 2; }
.widget--hero { grid-column: span 4; }

When I rendered this, a "wide" widget took two of the four columns, a "tall" one took two rows, and the small widgets filled the gaps in order. My offline study planner, StudyPilot, has a dashboard where each widget can be 1 to 4 columns wide and 1 to 3 rows tall. That kind of layout is a two-dimensional problem, which is Grid territory. Flexbox can't make an item span two rows.

Using Flexbox and Grid together

The best layouts often nest them. In the card grid above, Grid places the cards, and each card uses Flexbox inside to keep its "View" link at the bottom, even when descriptions have different lengths:

.card {
  display: flex;
  flex-direction: column;
  gap: 0.5rem;
  padding: 1.25rem;
  border: 1px solid #2c3550;
  border-radius: 12px;
}

.card a {
  margin-top: auto; /* pushes the link to the bottom of every card */
}

margin-top: auto on a flex item eats up all the free space above it, so the link sits at the bottom of every card. Because Grid makes all cards in a row the same height by default, the links line up across the row too.

Centring: both work

Centring something in a box is no longer hard. Both of these work:

/* Flexbox */
.center-flex {
  display: flex;
  justify-content: center;
  align-items: center;
  min-height: 300px;
}

/* Grid: one line does both axes */
.center-grid {
  display: grid;
  place-items: center;
  min-height: 300px;
}

I use the Grid version when I just want something centred, because place-items: center is one line. I use the Flexbox version when there are several items in a row that should be centred together.

Flexbox vs Grid: quick decision checklist

Items in a single row or column, sizes based on content: Flexbox.
Need items to line up in both rows and columns: Grid.
Need an item to span several rows: Grid.
Nav bars, button groups, tags, form rows, the inside of cards: Flexbox.
Page layouts, card galleries, dashboards, image galleries: Grid.
Not sure? Start with the one that needs less code, and switch if you find yourself fighting it.

Common mistakes

1. Using flex-wrap and expecting a grid

With flex-wrap: wrap, the last row often ends up with stretched or oddly sized items, because every flex line is sized separately. If you want neat columns, that's a sign you need Grid.

2. Forgetting min-width: 0

Flex and grid items have an automatic minimum size based on their content. Long words, URLs or inputs can then overflow the container. min-width: 0 on the item (or minmax(0, 1fr) for grid columns) lets them shrink.

3. Putting display on the wrong element

display: flex and display: grid go on the parent, and only affect its direct children. Grandchildren aren't laid out by it, unless you also make the child a flex or grid container (or use subgrid).

4. Confusing justify and align

In Flexbox, justify-content follows the main axis, which changes when you set flex-direction: column. If your centring suddenly works "the wrong way", check the direction.

5. Reordering content only visually

order and grid placement change where things appear, not the order a keyboard or screen reader follows. Keep the HTML in a logical order.

FAQ

Is CSS Grid better than Flexbox?

Neither is better. They solve different problems. Grid is for two-dimensional layouts, Flexbox is for one-dimensional ones, and they work well together.

Can I use Grid for everything?

You could build almost any layout with Grid, but simple rows like a nav bar or a button group take less code with Flexbox, and Flexbox handles items of unknown width more naturally.

What is subgrid?

grid-template-columns: subgrid (or rows) lets a nested grid reuse its parent's tracks, so content inside different cards can line up with each other. It's supported in all current major browsers.

Do I still need media queries?

Less often. Patterns like repeat(auto-fill, minmax(220px, 1fr)) and flex-wrap adapt on their own, but bigger changes, like moving a sidebar below the content, still use media queries or container queries.

Conclusion

Flexbox vs Grid isn't a competition. Reach for Flexbox for things in a line, Grid for things in rows and columns, and combine them freely. Grid for the page and the card list, Flexbox inside each card, is a pattern you'll use constantly.

If you want to go deeper, MDN has clear guides on basic concepts of grid layout and how it relates to Flexbox.

Originally published at mfaysal.com.

CSS Position Explained: Absolute vs Relative

mfaysal dev — Fri, 02 Oct 2026 10:52:05 +0000

CSS position decides how an element is placed. relative nudges an element from its normal spot but keeps its space in the layout; absolute takes it out of the layout and places it relative to the nearest positioned ancestor; fixed pins it to the viewport; and sticky acts normal until you scroll past a threshold, then sticks. The trick most beginners miss is that absolute needs a parent with position: relative. In this post I explain all five values with examples, and every behaviour I describe was checked by measuring elements in headless Chrome.

Positioning confused me for a long time. My absolutely positioned badges kept flying to the corner of the page, and my sticky headers refused to stick. Once I understood what each value is positioned relative to, it all clicked.

position: static (the default)

Every element starts as static. It sits in the normal flow of the page, and top, right, bottom, left and z-index have no effect. You rarely write position: static, except to undo another value.

position: relative

A relatively positioned element stays in the normal flow, and its original space is kept. The offsets move it visually from where it would have been:

.nudge {
  position: relative;
  top: 10px;   /* moves 10px down from where it would normally be */
  left: 20px;  /* and 20px to the right */
}

When I measured this, the nudged paragraph moved 20px to the right and 10px down, but the paragraph after it didn't move at all. The gap above the next paragraph shrank by exactly 10px, because the nudged one now overlaps the space below it. That's the key point: relative offsets don't push other elements around.

In practice I almost never use relative to nudge things. Its main job is the next section: being the anchor for absolutely positioned children.

position: absolute

An absolutely positioned element is removed from the normal flow. Other elements act as if it isn't there, and no space is left for it. Its offsets are measured from its containing block, which is the nearest ancestor with a position other than static. If there isn't one, it's positioned against the initial containing block, which is basically the first screen of the page.

Example: a "New" badge in the corner of a card

<article class="card">
  <span class="badge">New</span>
  <h2>CSS position explained</h2>
  <p>Absolute vs relative, fixed and sticky.</p>
</article>

.card {
  position: relative; /* becomes the containing block for .badge */
  padding: 1.5rem;
  border: 1px solid #2c3550;
  border-radius: 12px;
}

.badge {
  position: absolute;
  top: 12px;
  right: 12px;
  padding: 2px 10px;
  border-radius: 999px;
  background: #8b7cff;
  color: #fff;
}

With position: relative on the card, the badge sat 12px from the card's top and right edges, measured from inside the card's border. When I removed it, the badge jumped to 12px from the top of the page, far away from its card. That's the "flying badge" bug I kept hitting. The fix is always the same: give the parent position: relative.

Example: an overlay that covers its parent

.thumb {
  position: relative;
}

.thumb-overlay {
  position: absolute;
  inset: 0;              /* same as top: 0; right: 0; bottom: 0; left: 0; */
  display: grid;
  place-items: center;
  background: rgb(0 0 0 / 0.5);
}

inset is shorthand for all four offsets, and all major browsers support it. inset: 0 stretches the overlay over the whole parent, which is great for image captions, "play" buttons on video thumbnails and loading screens over a card.

Centring with absolute

.parent {
  position: relative;
  height: 300px;
}

.centered {
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
}

top: 50% and left: 50% move the element's top-left corner to the middle, and translate(-50%, -50%) shifts it back by half its own size. These days I usually centre with Grid or Flexbox instead, but this is still handy for overlays.

Positioned layers like these are how many editors draw handles and guides on top of content. When I built my canvas design and animation editor, I took a different route and drew selection handles directly on the canvas, but for normal web pages, absolute positioning inside a relative parent is the standard tool.

position: fixed

A fixed element is also taken out of the flow, but it's positioned relative to the viewport, so it stays in place when you scroll. It's used for "back to top" buttons, chat widgets and cookie banners:

.back-to-top {
  position: fixed;
  right: 1.5rem;
  bottom: 1.5rem;
  z-index: 10;
}

One surprise: if any ancestor has a transform, filter or perspective, that ancestor becomes the containing block, and "fixed" stops being fixed to the viewport. In my test, a fixed button inside a parent with transform: translateX(0) sat 24px from the bottom of that parent instead of the screen, and it scrolled away with it.

position: sticky

Sticky is a mix of relative and fixed. The element stays in the normal flow until it reaches a threshold you set, then sticks there while its parent is still on screen:

.site-header {
  position: sticky;
  top: 0;            /* required: where it should stick */
  z-index: 10;
  background: #10131c;
}

thead th {
  position: sticky;
  top: 0;
  background: #171b27;
}

Sticky headers and sticky table headings are the two uses I see most. Remember three rules:

You must set a threshold, such as top: 0. Without it, sticky behaves like relative.
The element only sticks within its parent. When the parent scrolls out of view, the sticky element goes with it.
Give it a background, otherwise content scrolls visibly underneath it.

z-index and stacking contexts

z-index controls which element is on top when they overlap. It works on positioned elements (and on flex and grid items). Higher numbers come forward, but only within the same stacking context:

.modal-wrapper {
  position: relative;
  z-index: 1;          /* creates a stacking context */
}

.modal {
  position: fixed;
  z-index: 9999;       /* only competes inside .modal-wrapper's context */
}

.header {
  position: sticky;
  top: 0;
  z-index: 2;          /* sits above the whole .modal-wrapper, modal included */
}

I tested this: even with z-index: 9999, the modal appeared under the header with z-index: 2, because the modal's wrapper created a stacking context with z-index: 1. The modal can never rise above its wrapper's level. When a huge z-index doesn't work, look for a parent that creates a stacking context: a positioned element with a z-index, or an element with opacity below 1, a transform or a filter.

Common mistakes with CSS position

1. Forgetting position: relative on the parent

The number one absolute-positioning bug. If an absolute element ends up in the wrong place, check which ancestor is the nearest positioned one.

2. Sticky inside overflow: hidden

Sticky elements stick to their nearest scrolling ancestor. overflow: hidden, auto or scroll on a parent makes that parent the scrolling ancestor, so if it doesn't scroll itself, the element never sticks.

/* Sticky silently stops working here */
.layout {
  overflow: hidden; /* any overflow other than visible on an ancestor */
}

/* Fix: use overflow: clip instead, which doesn't create a scroll container */
.layout--fixed {
  overflow: clip;
}

In my test, a sticky header inside an overflow: hidden wrapper scrolled away 500px off the screen. With overflow: clip, which hides overflow without creating a scroll container, the header stayed at top: 0.

3. Using absolute for page layout

Absolute elements don't take up space, so text under them doesn't move and things overlap as soon as the content or screen size changes. Use Flexbox or Grid for layout, and absolute only for small overlays.

4. Fighting z-index wars

Adding z-index: 99999 rarely fixes a stacking problem. Find the stacking context instead, and keep a small scale, like 1 for raised content, 10 for headers and 100 for modals.

5. Fixed elements covering content

A fixed header doesn't take up space, so the top of your page hides under it. Add padding to the body, or use position: sticky, which keeps its space.

FAQ

What's the difference between absolute and relative positioning?

Relative keeps the element in the flow and moves it from its normal spot. Absolute removes it from the flow and positions it inside the nearest positioned ancestor. They're often used together: relative on the parent, absolute on the child.

What's the difference between fixed and sticky?

Fixed is always pinned to the viewport and takes no space in the layout. Sticky stays in the layout and only sticks while scrolling, within its parent.

Why isn't my position: sticky working?

Check that you've set top (or another offset), that no ancestor has overflow set to hidden, auto or scroll, and that the parent is taller than the sticky element so it has room to stick.

Does z-index work without position?

On normal block elements, no. It works on positioned elements and on children of flex and grid containers.

Conclusion

Ask "relative to what?" for every position value: relative to its own normal spot, absolute to the nearest positioned ancestor, fixed to the viewport, and sticky to its scrolling ancestor once a threshold is reached. Add position: relative to parents of absolute children, avoid overflow: hidden around sticky elements, and look for stacking contexts when z-index acts strangely.

The MDN page on the CSS position property has interactive examples of each value if you want to experiment.

Originally published at mfaysal.com.

JavaScript map, filter and reduce Explained

mfaysal dev — Fri, 02 Oct 2026 10:52:03 +0000

In JavaScript, map() transforms every item in an array and returns a new array of the same length, filter() returns a new array with only the items that pass a test, and reduce() combines all the items into a single value, like a total or an object. None of them change the original array. Below I explain each one with practical examples, show how to chain them, and cover the mistakes that cost me the most debugging time.

Every example was run with Node.js 20 (and Node 22 for Object.groupBy), and the comments at the end of each block are the real output. The methods work the same way in every modern browser.

The sample data

Most of the examples use this small list of study tasks, saved as data.mjs, because real arrays are usually arrays of objects:

export const tasks = [
  { title: "Physics notes", subject: "Physics", minutes: 45, done: true },
  { title: "Math practice", subject: "Math", minutes: 60, done: false },
  { title: "Chemistry lab report", subject: "Chemistry", minutes: 90, done: false },
  { title: "Math revision", subject: "Math", minutes: 30, done: true },
  { title: "Physics problems", subject: "Physics", minutes: 50, done: false },
];

map(): transform every item

map() calls your function once for each item and builds a new array from whatever you return. Use it when you want "the same list, but each item changed".

import { tasks } from "./data.mjs";

const prices = [100, 250, 80];
const doubled = prices.map((price) => price * 2);
console.log(doubled);

const titles = tasks.map((task) => task.title);
console.log(titles);

// map also passes the index as the second argument
const numbered = titles.slice(0, 2).map((title, i) => `${i + 1}. ${title}`);
console.log(numbered);

console.log(prices); // the original array is unchanged

// Output:
// [ 200, 500, 160 ]
// [
//   'Physics notes',
//   'Math practice',
//   'Chemistry lab report',
//   'Math revision',
//   'Physics problems'
// ]
// [ '1. Physics notes', '2. Math practice' ]
// [ 100, 250, 80 ]

The callback gets the item first and the index second, which is handy for numbering. The input and output always have the same length. If you need fewer items, that's a job for filter().

filter(): keep only some items

filter() calls your function for each item and keeps the item if the function returns something truthy. Use it for "only the items where...".

import { tasks } from "./data.mjs";

const todo = tasks.filter((task) => !task.done);
console.log(todo.map((t) => t.title));

const longMath = tasks.filter((t) => t.subject === "Math" && t.minutes >= 45);
console.log(longMath.length, "long math task(s)");

const nothing = tasks.filter((t) => t.minutes > 500);
console.log(nothing); // no matches gives an empty array, not undefined

// Output:
// [ 'Math practice', 'Chemistry lab report', 'Physics problems' ]
// 1 long math task(s)
// []

When nothing matches, you get an empty array, not undefined or null. That means you can safely call .length or .map() on the result without checking first.

reduce(): combine everything into one value

reduce() is the one that confused me the longest. It walks through the array carrying an accumulator, the running result, and your function returns the new accumulator each time. The second argument to reduce() is the starting value.

import { tasks } from "./data.mjs";

const numbers = [5, 10, 15];
const sum = numbers.reduce((total, n) => total + n, 0);
console.log(sum);

// Total minutes across all tasks
const totalMinutes = tasks.reduce((total, task) => total + task.minutes, 0);
console.log(`${totalMinutes} minutes`);

// Count tasks per subject: the accumulator is an object
const perSubject = tasks.reduce((counts, task) => {
  counts[task.subject] = (counts[task.subject] ?? 0) + 1;
  return counts;
}, {});
console.log(perSubject);

// Output:
// 30
// 275 minutes
// { Physics: 2, Math: 2, Chemistry: 1 }

What helped me was logging each step:

[5, 10, 15].reduce((total, n) => {
  console.log(`total=${total}, n=${n} -> ${total + n}`);
  return total + n;
}, 0);

// Output:
// total=0, n=5 -> 5
// total=5, n=10 -> 15
// total=15, n=15 -> 30

The accumulator doesn't have to be a number. In the perSubject example it's an object that collects counts. The ?? 0 handles the first time a subject appears, when its count doesn't exist yet. Always return the accumulator, otherwise the next step gets undefined.

Grouping: reduce vs Object.groupBy

Grouping items by a key used to be the classic reduce() exercise. Modern JavaScript has a built-in for it:

import { tasks } from "./data.mjs";

// Object.groupBy: Node 21+, and all current major browsers
const bySubject = Object.groupBy(tasks, (task) => task.subject);
console.log(Object.keys(bySubject));
console.log(bySubject.Math.map((t) => t.title));

// Output:
// [ 'Physics', 'Math', 'Chemistry' ]
// [ 'Math practice', 'Math revision' ]

Object.groupBy is available in Node.js 21 and later and in current versions of the major browsers. It isn't in Node 20, which I confirmed by running it there, so if your code has to run on older environments, the reduce() version above still works everywhere.

Chaining map, filter and reduce

Because map() and filter() return arrays, you can chain them. Each step reads like a sentence:

import { tasks } from "./data.mjs";

// Hours of study left on unfinished tasks
const hoursLeft = tasks
  .filter((task) => !task.done)               // keep unfinished tasks
  .map((task) => task.minutes)                 // turn each into its minutes
  .reduce((total, minutes) => total + minutes, 0) / 60; // add them up

console.log(`${hoursLeft.toFixed(2)} hours left`);

// Titles of unfinished tasks, longest first, without changing the original
const plan = tasks
  .filter((t) => !t.done)
  .toSorted((a, b) => b.minutes - a.minutes)
  .map((t) => `${t.title} (${t.minutes} min)`);
console.log(plan);

// Output:
// 3.33 hours left
// [
//   'Chemistry lab report (90 min)',
//   'Math practice (60 min)',
//   'Physics problems (50 min)'
// ]

I put each method on its own line so it's easy to comment out a step while debugging. The second example uses toSorted(), which returns a sorted copy. The older sort() sorts the array in place, which can quietly change data other code depends on.

This style of small, pure functions, where the same data in always gives the same result out, is how I wrote the planner in my study app. Each task gets a score and the plan is built from the sorted list. I wrote about it in building an offline study planner with no backend. Pure functions like these are also very easy to test.

Which one should I use?

When I'm not sure, I ask what I want to get back:

An array of the same length, with each item changed? Use map().
A shorter array with some items removed? Use filter().
A single value, like a number, string or object? Use reduce().

Real tasks usually need more than one. Here's a small report from a list of exam results that uses all three, each for its own job:

const results = [
  { name: "Rafi", mark: 72 },
  { name: "Nusrat", mark: 88 },
  { name: "Tanvir", mark: 35 },
  { name: "Mim", mark: 64 },
];

const passed = results.filter((r) => r.mark >= 40);
const average = passed.reduce((sum, r) => sum + r.mark, 0) / passed.length;
const names = passed.map((r) => r.name).join(", ");

console.log(`${passed.length} passed: ${names}`);
console.log(`Average of passing marks: ${average.toFixed(1)}`);

// Output:
// 3 passed: Rafi, Nusrat, Mim
// Average of passing marks: 74.7

You could do all of this inside one big reduce(), but splitting it up keeps each line simple. I'd rather loop over four items three times than read one clever line that nobody understands a week later. Notice that the average divides by passed.length. If nobody passed, that would be zero and the result would be NaN, so real code should check for an empty list first.

Related methods worth knowing

Sometimes filter() is more than you need:

import { tasks } from "./data.mjs";

console.log(tasks.find((t) => t.subject === "Chemistry").title); // first match
console.log(tasks.some((t) => t.minutes > 60));   // at least one?
console.log(tasks.every((t) => t.minutes >= 30)); // all of them?
console.log(tasks.findIndex((t) => !t.done));     // index of first match

// Output:
// Chemistry lab report
// true
// true
// 1

find() returns the first matching item itself (or undefined), not an array.
some() and every() return true or false and stop as soon as they know the answer.
findIndex() returns the position, or -1 if nothing matches.

If you write filter(...)[0] or filter(...).length > 0, there's a clearer method for it.

Common mistakes with map, filter and reduce

1. Forgetting return in an arrow function with braces

const nums = [1, 2, 3];

const broken = nums.map((n) => { n * 2 });       // braces need a return
const fixed = nums.map((n) => { return n * 2; });
const short = nums.map((n) => n * 2);            // or drop the braces

console.log(broken, fixed, short);

// Returning an object without braces needs parentheses
const objs = nums.map((n) => ({ value: n }));
console.log(objs);

// Output:
// [ undefined, undefined, undefined ] [ 2, 4, 6 ] [ 2, 4, 6 ]
// [ { value: 1 }, { value: 2 }, { value: 3 } ]

With curly braces, the arrow function has a body and needs an explicit return. Without braces, the expression is returned automatically. To return an object literal without braces, wrap it in parentheses, or JavaScript reads the braces as a function body.

2. Passing a function that takes extra arguments

const inputs = ["10", "10", "10"];

console.log(inputs.map(parseInt));                 // index becomes the radix!
console.log(inputs.map((s) => parseInt(s, 10)));   // pass only what you mean
console.log(inputs.map(Number));

// Output:
// [ 10, NaN, 2 ]
// [ 10, 10, 10 ]
// [ 10, 10, 10 ]

map() passes the item, the index and the array. parseInt takes a second argument, the radix, so it receives the index as the base. parseInt("10", 1) is NaN and parseInt("10", 2) is 2. Wrap it in an arrow function, or use Number.

3. Calling reduce on an empty array without a starting value

const empty = [];

try {
  empty.reduce((a, b) => a + b);   // no initial value
} catch (error) {
  console.log(error.constructor.name + ":", error.message);
}

console.log(empty.reduce((a, b) => a + b, 0)); // initial value makes it safe

// Output:
// TypeError: Reduce of empty array with no initial value
// 0

Without an initial value, reduce() uses the first item as the start, and with no first item it throws. I always pass an initial value. It also makes the type of the result obvious to anyone reading.

4. Mutating objects inside map

const users = [{ name: "Rafi", active: false }];

// Wrong: this changes the original objects
const activated = users.map((u) => { u.active = true; return u; });
console.log(users[0].active); // true - the original was modified

// Right: return a new object with spread
const users2 = [{ name: "Rafi", active: false }];
const activated2 = users2.map((u) => ({ ...u, active: true }));
console.log(users2[0].active, activated2[0].active);

// Output:
// true
// false true

map() creates a new array, but the objects inside are the same objects. Changing them changes the original data. Spread into a new object instead.

5. Using map just to loop

If you don't use the returned array, use forEach() or a for...of loop. A map() whose result is thrown away tells the reader the wrong thing.

FAQ

What's the difference between map and forEach?

map() returns a new array built from your return values. forEach() returns undefined and is only for side effects, like logging or updating the page.

Do map, filter and reduce change the original array?

No, they return new values. But if the items are objects and your callback modifies them, those objects are changed, because both arrays point to the same objects.

Is chaining slow because it loops several times?

Each step is a separate loop, but for the arrays most apps deal with (hundreds or a few thousand items) the difference is too small to notice. Readability wins. If you ever process huge datasets, measure before optimising.

Can I use these methods on objects?

Not directly, but Object.entries(obj) turns an object into an array of [key, value] pairs you can map and filter, and Object.fromEntries() turns it back.

Conclusion

Use map() to change every item, filter() to keep some items and reduce() to boil them down to one value, and chain them to describe a data pipeline step by step. Always give reduce() a starting value, return from braced arrow functions, and avoid mutating objects inside callbacks.

MDN's reference for Array.prototype.reduce() has more examples, and the pages for map and filter are linked from there.

Originally published at mfaysal.com.

PHP Form Validation and Sanitization Guide

mfaysal dev — Fri, 02 Oct 2026 10:51:54 +0000

To validate and sanitize a PHP form safely: read each field from $_POST with a default, trim() it, check it against clear rules with functions like filter_var(), mb_strlen() and an allow-list, collect the errors in an array, and only use the data when there are none. Then escape every value with htmlspecialchars() when you output it into HTML, and use prepared statements when you store it. In this guide I build a complete contact form handler step by step on PHP 8.4, including CSRF protection and the Post/Redirect/Get pattern.

When I started with PHP, I thought "sanitizing" meant running every input through a magic function and calling it safe. That's not how it works. There are two separate jobs: validation (is this input acceptable?) and escaping (make this value safe for the place it's going). I tested every snippet here with php-cli, and I ran the full form on PHP's built-in server and sent real requests to it with curl.

Validation vs sanitization vs escaping

Validation checks the input and rejects it if it's wrong: the email isn't an email, the age is out of range, the message is empty. You tell the user and let them fix it.
Sanitization changes the input into an acceptable shape, like trimming spaces. Keep this minimal. Silently changing what someone typed often hides bugs.
Escaping happens at output time and depends on where the value goes: htmlspecialchars() for HTML, prepared statements for SQL, escapeshellarg() for shell commands.

The rule I follow now: validate on input, escape on output.

Step 1: a validation function

I keep validation in a plain function that takes an array and returns the clean data plus an array of errors. That makes it easy to test without a browser:

<?php
declare(strict_types=1);

/**
 * Validate a contact form submission.
 * Returns [cleanData, errors]. Errors are keyed by field name.
 */
function validate_contact(array $input): array
{
    $errors = [];

    // 1. Read each field as a trimmed string. Missing fields or arrays
    //    (someone sending name[]=x) become an empty string.
    $field = fn(string $key): string =>
        is_string($input[$key] ?? null) ? trim($input[$key]) : '';

    $name    = $field('name');
    $email   = $field('email');
    $age     = $field('age');
    $topic   = $field('topic');
    $message = $field('message');

    // 2. Validate each one
    if ($name === '') {
        $errors['name'] = 'Please enter your name.';
    } elseif (mb_strlen($name) > 60) {
        $errors['name'] = 'Name must be 60 characters or fewer.';
    }

    if (filter_var($email, FILTER_VALIDATE_EMAIL) === false) {
        $errors['email'] = 'Please enter a valid email address.';
    }

    $ageInt = null;
    if ($age !== '') {
        $ageInt = filter_var($age, FILTER_VALIDATE_INT, [
            'options' => ['min_range' => 13, 'max_range' => 120],
        ]);
        if ($ageInt === false) {
            $errors['age'] = 'Age must be a whole number from 13 to 120.';
        }
    }

    $allowedTopics = ['project', 'freelance', 'question'];
    if (!in_array($topic, $allowedTopics, true)) {
        $errors['topic'] = 'Please choose a topic from the list.';
    }

    $length = mb_strlen($message);
    if ($length < 10 || $length > 2000) {
        $errors['message'] = 'Message must be between 10 and 2000 characters.';
    }

    $clean = [
        'name' => $name,
        'email' => $email,
        'age' => $ageInt,
        'topic' => $topic,
        'message' => $message,
    ];

    return [$clean, $errors];
}

A few choices here are deliberate:

The $field helper handles missing fields and also the case where someone sends name[]=x, which makes $_POST['name'] an array. Without the check, that causes warnings or type errors.
FILTER_VALIDATE_EMAIL checks the email format. It doesn't prove the address exists. Only a confirmation email can do that.
FILTER_VALIDATE_INT with min_range/max_range rejects 12.5, 19abc and out-of-range numbers in one call. Note the check for === false: a valid value of 0 is falsy, so a loose check would treat it as an error.
An allow-list for the topic. For selects, radio buttons and checkboxes, never trust that the value is one of your options. Anyone can edit the HTML or send a raw request. in_array(..., true) uses strict comparison.
mb_strlen() instead of strlen(). More on that in the mistakes section.

Step 2: test it from the command line

<?php
require __DIR__ . '/validate.php';

// A good submission (note the extra spaces and Bangla text)
[$data, $errors] = validate_contact([
    'name' => '  Mahir Faysal ',
    'email' => 'mahir@example.com',
    'age' => '19',
    'topic' => 'project',
    'message' => 'আমি একটি ওয়েবসাইট চাই। Can we talk?',
]);
var_dump($errors);
echo $data['name'], ' | age ', $data['age'], "\n";

// A bad submission
[, $errors] = validate_contact([
    'name' => '',
    'email' => 'not-an-email',
    'age' => '12.5',
    'topic' => 'admin',
    'message' => 'hi',
]);
print_r($errors);

// Someone sends arrays instead of strings: no warnings, just errors
[, $errors] = validate_contact(['name' => ['x'], 'email' => ['a@b.c']]);
echo count($errors), " errors\n";

// Output:
// array(0) {
// }
// Mahir Faysal | age 19
// Array
// (
//     [name] => Please enter your name.
//     [email] => Please enter a valid email address.
//     [age] => Age must be a whole number from 13 to 120.
//     [topic] => Please choose a topic from the list.
//     [message] => Message must be between 10 and 2000 characters.
// )
// 4 errors

The good submission, with extra spaces and a Bangla message, passes and comes back trimmed. The bad one produces a clear message for every field, and the array input doesn't cause a single warning. I always test validation like this before wiring up the HTML.

Step 3: escape on output with htmlspecialchars()

Whatever the user typed must never be printed into HTML as-is, or a value like <script> runs in your visitors' browsers. That's cross-site scripting (XSS).

<?php
$comment = '<script>alert("hacked")</script> Tom & Jerry\'s "show"';

// Escape when you OUTPUT into HTML, not when you save
echo htmlspecialchars($comment, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8'), "\n";

// A tiny helper so you never forget the flags
function e(?string $value): string
{
    return htmlspecialchars($value ?? '', ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
}

echo '<input name="name" value="' . e('Rafi "the coder"') . '">', "\n";

// Output:
// &lt;script&gt;alert(&quot;hacked&quot;)&lt;/script&gt; Tom &amp; Jerry&#039;s &quot;show&quot;
// <input name="name" value="Rafi &quot;the coder&quot;">

Since PHP 8.1, htmlspecialchars() escapes both double and single quotes by default, but I still pass ENT_QUOTES | ENT_SUBSTITUTE and 'UTF-8' explicitly, so the code is safe on any version and obvious to read. The short e() helper means I never have to remember the flags. Escape inside attributes too, like value="...", not just in text.

Step 4: the complete form with CSRF protection

Here's the full page. It shows the form on GET, validates on POST, keeps what the user typed when there are errors, and redirects after a successful submission:

<?php
declare(strict_types=1);
session_start();
require __DIR__ . '/validate.php';

function e(?string $value): string
{
    return htmlspecialchars($value ?? '', ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');
}

// One CSRF token per session
if (empty($_SESSION['csrf'])) {
    $_SESSION['csrf'] = bin2hex(random_bytes(32));
}

$errors = [];
$old = [];

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    $token = (string) ($_POST['csrf'] ?? '');
    if (!hash_equals($_SESSION['csrf'], $token)) {
        http_response_code(400);
        exit('Invalid form token. Please reload the page and try again.');
    }

    [$data, $errors] = validate_contact($_POST);
    // Keep what the user typed so they don't have to start again
    $old = array_map(fn($v) => is_string($v) ? trim($v) : '', $_POST);

    if ($errors === []) {
        // Save or email $data here (with prepared statements for the database)
        $_SESSION['flash'] = 'Thanks, ' . $data['name'] . '! Your message was sent.';
        header('Location: ' . $_SERVER['PHP_SELF'], true, 303); // Post/Redirect/Get
        exit;
    }
    http_response_code(422);
}

$flash = $_SESSION['flash'] ?? '';
unset($_SESSION['flash']);
?>
<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Contact</title>
</head>
<body>
<?php if ($flash !== ''): ?>
  <p><?= e($flash) ?></p>
<?php endif; ?>

<form method="post" novalidate>
  <input type="hidden" name="csrf" value="<?= e($_SESSION['csrf']) ?>">

  <label for="name">Name</label>
  <input id="name" name="name" type="text" value="<?= e($old['name'] ?? '') ?>" required maxlength="60">
  <?php if (isset($errors['name'])): ?><p><?= e($errors['name']) ?></p><?php endif; ?>

  <label for="email">Email</label>
  <input id="email" name="email" type="email" value="<?= e($old['email'] ?? '') ?>" required>
  <?php if (isset($errors['email'])): ?><p><?= e($errors['email']) ?></p><?php endif; ?>

  <label for="age">Age (optional)</label>
  <input id="age" name="age" type="number" min="13" max="120" value="<?= e($old['age'] ?? '') ?>">
  <?php if (isset($errors['age'])): ?><p><?= e($errors['age']) ?></p><?php endif; ?>

  <label for="topic">Topic</label>
  <select id="topic" name="topic">
    <?php foreach (['project' => 'A project', 'freelance' => 'Freelance work', 'question' => 'A question'] as $value => $label): ?>
      <option value="<?= e($value) ?>"<?= ($old['topic'] ?? '') === $value ? ' selected' : '' ?>><?= e($label) ?></option>
    <?php endforeach; ?>
  </select>
  <?php if (isset($errors['topic'])): ?><p><?= e($errors['topic']) ?></p><?php endif; ?>

  <label for="message">Message</label>
  <textarea id="message" name="message" required minlength="10" maxlength="2000"><?= e($old['message'] ?? '') ?></textarea>
  <?php if (isset($errors['message'])): ?><p><?= e($errors['message']) ?></p><?php endif; ?>

  <button type="submit">Send</button>
</form>
</body>
</html>

What each part does:

CSRF token. A random token is stored in the session and added to the form as a hidden field. On POST, hash_equals() compares them in constant time. This stops another site from submitting the form on behalf of a logged-in visitor. In my test, a POST with a wrong token got a 400 response.
Sticky values. When validation fails, the form is shown again with a 422 status and the user's input, escaped. I sent <b>Rafi</b> "x" as the name, and it came back as harmless text in the value attribute.
Post/Redirect/Get. After a successful POST, a 303 redirect sends the browser back with GET. Refreshing the page then won't resubmit the form. The success message is stored in the session and removed after it's shown once.
novalidate on the form is there so I could test the server side. On a real site, remove it and keep the HTML required, maxlength and type attributes for instant feedback. They're a convenience, not protection.

This "check everything on the server, whatever the client did" idea is the same one I used in a Next.js project, where the API route checks each request against a strict schema and rejects unknown fields. I wrote about it in how I kept my AI API key off the browser.

Common mistakes in PHP form validation

1. Using FILTER_SANITIZE_STRING

Many older tutorials still use it. It has been deprecated since PHP 8.1, and on PHP 8.4 using it prints a deprecation notice. It also mangled legitimate input. Validate the value and escape it on output instead.

2. Escaping on input instead of output

Running htmlspecialchars() before saving to the database stores &-style text, which then gets double-escaped or breaks in emails and JSON. Store the clean original, and escape for the specific output.

3. Counting bytes instead of characters

<?php
$name = 'মাহির';
echo strlen($name), "\n";    // bytes
echo mb_strlen($name), "\n"; // characters

// Output:
// 15
// 5

A five-letter Bangla name is 15 bytes in UTF-8. With strlen(), a limit of 60 "characters" would reject names far shorter than you meant to allow. Use mb_strlen() for user-facing length limits (it needs the mbstring extension, which most hosts enable).

4. Trusting filter_var with URLs

<?php
var_dump(filter_var('42', FILTER_VALIDATE_INT));
var_dump(filter_var('42abc', FILTER_VALIDATE_INT));
var_dump(filter_var('0', FILTER_VALIDATE_INT));      // valid, but falsy!
var_dump(filter_var('yes', FILTER_VALIDATE_BOOLEAN));
var_dump(filter_var('https://mfaysal.com', FILTER_VALIDATE_URL));
var_dump(filter_var('javascript://x%0Aalert(1)', FILTER_VALIDATE_URL)); // passes!

// So also check the scheme yourself before using a URL in a link
$url = 'javascript://x%0Aalert(1)';
$scheme = parse_url($url, PHP_URL_SCHEME);
var_dump(in_array($scheme, ['http', 'https'], true));

// Output:
// int(42)
// bool(false)
// int(0)
// bool(true)
// string(19) "https://mfaysal.com"
// string(25) "javascript://x%0Aalert(1)"
// bool(false)

FILTER_VALIDATE_URL checks the format, not whether the URL is safe. A javascript: URL can pass. If you're going to put a URL into a link, also check that the scheme is http or https.

5. Using $_REQUEST or skipping the method check

$_REQUEST mixes GET, POST and cookies, so you can't be sure where a value came from. Read from $_POST and check $_SERVER['REQUEST_METHOD'].

FAQ

Is HTML5 validation enough?

No. It improves the experience, but anyone can bypass it with dev tools or by sending a request directly. Server-side validation is required. Client-side validation is optional.

Should I use strip_tags()?

Usually not. It deletes parts of what the user typed, such as anything after a < in "a <3 b". Escaping on output with htmlspecialchars() keeps the text and makes it safe.

How do I save the validated data to MySQL safely?

Use PDO with prepared statements and pass the values separately from the SQL. Validation and prepared statements protect against different problems, so you need both.

Where should I show the error messages?

Next to each field, as in the example, plus a short summary at the top for long forms. Keep the user's input so they only fix what's wrong.

Conclusion

Secure PHP form handling comes down to a few habits: read inputs defensively, validate with filter_var(), mb_strlen() and allow-lists, collect errors and redisplay the form with the user's input, protect it with a CSRF token, redirect after success, and escape everything on output with htmlspecialchars().

The PHP manual's page on filter_var() links to the full list of validation filters and their options, and the htmlspecialchars() page next to it explains every flag.

Originally published at mfaysal.com.

PHP PDO Prepared Statements for Beginners

mfaysal dev — Fri, 02 Oct 2026 10:51:35 +0000

A PDO prepared statement keeps your SQL and your data apart: you write the query with placeholders like ? or :email, call $pdo->prepare(), then pass the real values to execute(). The database never treats those values as SQL, which is what protects you from SQL injection. In this beginner tutorial I connect to MySQL with PDO, then insert, select, update and delete with prepared statements, and cover LIKE searches, IN lists, LIMIT, transactions and the mistakes I made.

I ran every example on PHP 8.4 against a real MariaDB database (MariaDB works the same as MySQL for everything here), and the comments at the end of each block show the actual output. The examples run in order, so the data changes as you go.

Why prepared statements matter

Here's the problem in one example. Imagine a login or search box where someone types nobody@example.com' OR '1'='1:

<?php
require __DIR__ . '/db.php';

$email = "nobody@example.com' OR '1'='1"; // what an attacker might type

// UNSAFE: the input becomes part of the SQL itself
$rows = $pdo->query("SELECT name FROM students WHERE email = '$email'")->fetchAll();
echo "Unsafe query returned ", count($rows), " rows\n";

// SAFE: the input is sent separately as a value
$stmt = $pdo->prepare('SELECT name FROM students WHERE email = ?');
$stmt->execute([$email]);
echo "Prepared query returned ", count($stmt->fetchAll()), " rows\n";

// Output:
// Unsafe query returned 4 rows
// Prepared query returned 0 rows

When the input is pasted straight into the SQL string, the quote closes the email value early and OR '1'='1' becomes part of the query. It's always true, so the unsafe version returned every student in the table. The prepared version sent the whole input as one plain value, found no student with that strange "email", and returned nothing. That's the whole point of prepared statements.

Connecting to MySQL with PDO

I keep the connection in one file and require it everywhere else:

<?php
// db.php - keep this file outside your public web folder if you can
$host = getenv('DB_HOST') ?: '127.0.0.1';
$name = getenv('DB_NAME') ?: 'school';
$user = getenv('DB_USER') ?: 'app';
$pass = getenv('DB_PASS') ?: '';

$dsn = "mysql:host=$host;dbname=$name;charset=utf8mb4";

$pdo = new PDO($dsn, $user, $pass, [
    PDO::ATTR_ERRMODE            => PDO::ERRMODE_EXCEPTION, // throw on errors
    PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,       // rows as ['col' => value]
    PDO::ATTR_EMULATE_PREPARES   => false,                  // real prepared statements
]);

charset=utf8mb4 in the DSN makes the connection use full UTF-8, so Bangla text and emoji are stored correctly.
ERRMODE_EXCEPTION makes PDO throw a PDOException when something goes wrong. Since PHP 8.0 this is the default, but I set it explicitly so nobody has to wonder.
FETCH_ASSOC returns rows as arrays keyed by column name, instead of duplicating every value under a number too.
EMULATE_PREPARES => false asks MySQL to do the preparing itself, and it changes some behaviour you'll see later.
Credentials come from environment variables, not hard-coded in the file. Don't commit passwords to Git, and don't show connection errors to visitors, because the message can reveal details about your server.

For the examples I created a small table:

<?php
require __DIR__ . '/db.php';

$pdo->exec('DROP TABLE IF EXISTS enrolments, students');
$pdo->exec('CREATE TABLE students (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(60) NOT NULL,
    email VARCHAR(255) NOT NULL UNIQUE,
    class_level INT NOT NULL
)');

echo "Table ready\n";

// Output:
// Table ready

INSERT with named placeholders

<?php
require __DIR__ . '/db.php';

$stmt = $pdo->prepare(
    'INSERT INTO students (name, email, class_level) VALUES (:name, :email, :level)'
);

$students = [
    ['name' => 'Rafi',   'email' => 'rafi@example.com',   'level' => 10],
    ['name' => 'Nusrat', 'email' => 'nusrat@example.com', 'level' => 11],
    ['name' => 'Tanvir', 'email' => 'tanvir@example.com', 'level' => 10],
    ['name' => 'Mim',    'email' => 'mim@example.com',    'level' => 12],
];

foreach ($students as $s) {
    $stmt->execute($s); // prepare once, execute many times
    echo "Inserted {$s['name']} with id ", $pdo->lastInsertId(), "\n";
}

// Output:
// Inserted Rafi with id 1
// Inserted Nusrat with id 2
// Inserted Tanvir with id 3
// Inserted Mim with id 4

Named placeholders like :name make longer queries easier to read. The array keys match the placeholder names, and the leading colon in the keys is optional. Notice that I call prepare() once and execute() four times. The query is parsed once and reused, which is cleaner and can be faster for repeated inserts. lastInsertId() gives you the auto-increment ID of the new row.

SELECT: one row, many rows, one column

<?php
require __DIR__ . '/db.php';

// One row, positional ? placeholder
$stmt = $pdo->prepare('SELECT id, name, class_level FROM students WHERE email = ?');
$stmt->execute(['nusrat@example.com']);
$student = $stmt->fetch(); // an array, or false if no row matched

if ($student === false) {
    echo "Not found\n";
} else {
    echo "{$student['name']} is in class {$student['class_level']}\n";
}

// Many rows, named placeholder
$stmt = $pdo->prepare('SELECT name FROM students WHERE class_level = :level ORDER BY name');
$stmt->execute(['level' => 10]);
foreach ($stmt->fetchAll() as $row) {
    echo "- {$row['name']}\n";
}

// Just one column from every row
$stmt = $pdo->prepare('SELECT name FROM students WHERE class_level >= ?');
$stmt->execute([11]);
print_r($stmt->fetchAll(PDO::FETCH_COLUMN));

// Output:
// Nusrat is in class 11
// - Rafi
// - Tanvir
// Array
// (
//     [0] => Nusrat
//     [1] => Mim
// )

fetch() returns the next row, or false when there are no more. Always check for false before using the result.
fetchAll() returns every row as an array. That's fine for small results. For thousands of rows, loop with fetch() instead.
fetchAll(PDO::FETCH_COLUMN) gives a flat array of the first column, which is perfect for lists of names or IDs.

Positional ? placeholders are filled in order from a plain array. You can use either style, but not both in the same query.

LIKE searches and IN lists

These two confuse almost every beginner, because the "obvious" way doesn't work:

<?php
require __DIR__ . '/db.php';

// LIKE: put the % signs in the value, not in the SQL
$search = 'a';
$stmt = $pdo->prepare('SELECT name FROM students WHERE name LIKE ? ORDER BY name');
$stmt->execute(['%' . $search . '%']);
echo implode(', ', $stmt->fetchAll(PDO::FETCH_COLUMN)), "\n";

// IN (...): build one ? per value
$ids = [1, 3, 4];
$placeholders = implode(', ', array_fill(0, count($ids), '?'));
$stmt = $pdo->prepare("SELECT name FROM students WHERE id IN ($placeholders)");
$stmt->execute($ids);
echo implode(', ', $stmt->fetchAll(PDO::FETCH_COLUMN)), "\n";

// Output:
// Nusrat, Rafi, Tanvir
// Rafi, Tanvir, Mim

For LIKE, the % wildcards belong in the value you pass, not around the placeholder in the SQL. For IN, one placeholder can only hold one value, so you generate a ? for each item and pass the array. Never implode() the values themselves into the SQL.

LIMIT, OFFSET and dynamic ORDER BY

<?php
require __DIR__ . '/db.php';

// LIMIT/OFFSET: bind as integers
$perPage = 2;
$page = 2;
$stmt = $pdo->prepare('SELECT name FROM students ORDER BY id LIMIT :limit OFFSET :offset');
$stmt->bindValue(':limit', $perPage, PDO::PARAM_INT);
$stmt->bindValue(':offset', ($page - 1) * $perPage, PDO::PARAM_INT);
$stmt->execute();
echo "Page 2: ", implode(', ', $stmt->fetchAll(PDO::FETCH_COLUMN)), "\n";

// ORDER BY a column chosen by the user: placeholders can't be used for
// column names, so map the input to an allow-list instead
$sortInput = $_GET['sort'] ?? 'name'; // pretend this came from the URL
$columns = ['name' => 'name', 'level' => 'class_level'];
$orderBy = $columns[$sortInput] ?? 'name';

$rows = $pdo->query("SELECT name FROM students ORDER BY $orderBy")->fetchAll(PDO::FETCH_COLUMN);
echo "Sorted by $orderBy: ", implode(', ', $rows), "\n";

// Output:
// Page 2: Tanvir, Mim
// Sorted by name: Mim, Nusrat, Rafi, Tanvir

For pagination, I bind LIMIT and OFFSET with bindValue() and PDO::PARAM_INT. This matters when emulated prepares are on: in my test, passing a LIMIT value as a string through execute() worked with emulation off but failed with a syntax error (SQLSTATE 42000) with emulation on, because PDO quoted it as '2'. Binding as an integer works in both modes.

Placeholders only work for values. You can't use them for table names, column names or keywords like ASC. When the user picks a sort column, map their choice to a fixed list of real column names, and fall back to a default for anything else. The user's input then never reaches the SQL at all.

UPDATE and DELETE with rowCount()

<?php
require __DIR__ . '/db.php';

$stmt = $pdo->prepare('UPDATE students SET class_level = class_level + 1 WHERE class_level = ?');
$stmt->execute([10]);
echo $stmt->rowCount(), " students moved up\n";

$stmt = $pdo->prepare('DELETE FROM students WHERE email = ?');
$stmt->execute(['nobody@example.com']);
echo $stmt->rowCount(), " rows deleted\n"; // 0: no error, just nothing matched

// Output:
// 2 students moved up
// 0 rows deleted

rowCount() tells you how many rows were changed. A query that matches nothing isn't an error, so check this when you need to know whether something actually happened, like showing "not found" when deleting a record that doesn't exist.

Transactions: all or nothing

When several queries must succeed together, wrap them in a transaction. If anything fails, rollBack() undoes all of it:

<?php
require __DIR__ . '/db.php';

$pdo->exec('CREATE TABLE IF NOT EXISTS enrolments (
    student_id INT NOT NULL,
    course VARCHAR(40) NOT NULL
)');

try {
    $pdo->beginTransaction();

    $stmt = $pdo->prepare('INSERT INTO students (name, email, class_level) VALUES (?, ?, ?)');
    $stmt->execute(['Sadia', 'sadia@example.com', 9]);
    $id = (int) $pdo->lastInsertId();

    $stmt = $pdo->prepare('INSERT INTO enrolments (student_id, course) VALUES (?, ?)');
    $stmt->execute([$id, 'Web Development']);

    // Same email again: the UNIQUE column makes this fail
    $stmt = $pdo->prepare('INSERT INTO students (name, email, class_level) VALUES (?, ?, ?)');
    $stmt->execute(['Sadia again', 'sadia@example.com', 9]);

    $pdo->commit();
} catch (PDOException $e) {
    $pdo->rollBack();
    echo "Rolled back: SQLSTATE ", $e->getCode(), "\n";
}

$count = $pdo->query("SELECT COUNT(*) FROM students WHERE email = 'sadia@example.com'")->fetchColumn();
echo "Sadia rows saved: $count\n";

// Output:
// Rolled back: SQLSTATE 23000
// Sadia rows saved: 0

The third insert broke the UNIQUE rule on the email column. Because everything was in one transaction, the first two inserts were undone too, and Sadia wasn't saved in a half-finished state. Transactions need a storage engine that supports them, like InnoDB, which is MySQL's default.

Common mistakes with PDO prepared statements

1. Preparing a query that already contains user input

$pdo->prepare("SELECT * FROM users WHERE id = $id") isn't protected at all, because the value was already pasted into the SQL before prepare() saw it. The value must go into execute() or bindValue().

2. Reusing a named placeholder

<?php
require __DIR__ . '/db.php';

try {
    // The same named placeholder twice, with emulated prepares turned off
    $stmt = $pdo->prepare('SELECT name FROM students WHERE name = :term OR email = :term');
    $stmt->execute(['term' => 'Rafi']);
} catch (PDOException $e) {
    echo "Error: SQLSTATE ", $e->getCode(), "\n";
}

// Fix: give each placeholder its own name
$stmt = $pdo->prepare('SELECT name FROM students WHERE name = :name OR email = :email');
$stmt->execute(['name' => 'Rafi', 'email' => 'Rafi']);
echo $stmt->fetchColumn(), "\n";

// Output:
// Error: SQLSTATE HY093
// Rafi

With emulated prepares turned off, each named placeholder can appear only once, otherwise you get SQLSTATE HY093 ("invalid parameter number"). Give each one its own name, even if the value is the same.

3. Quotes around placeholders

WHERE email = '?' searches for a literal question mark. Placeholders never get quotes. PDO handles that.

4. Showing raw database errors to users

Catch PDOException, log the details, and show a friendly message. Error messages can reveal table names, queries or connection details.

5. Thinking prepared statements replace validation

Prepared statements stop SQL injection, but they don't check that an email is an email or that a number is in range. Validate first, then store.

FAQ

PDO or MySQLi: which should I learn?

Both support prepared statements. I prefer PDO because the same API works with MySQL, SQLite, PostgreSQL and other databases, and named placeholders make queries easier to read.

bindValue, bindParam or execute with an array?

Passing an array to execute() is the simplest and covers most cases. bindValue() lets you set a type, such as PARAM_INT. bindParam() binds a variable by reference, so its value is read when execute() runs, which beginners rarely need.

Do I still need to escape output if I use prepared statements?

Yes. Prepared statements protect the database. When you print data from the database into a page, escape it with htmlspecialchars() to protect against XSS.

Is the connection closed automatically?

Yes, PHP closes it when the script ends. You can set $pdo = null to close it earlier, but in a normal web request you don't need to.

Conclusion

PDO prepared statements come down to one habit: SQL with placeholders goes into prepare(), values go into execute(). Connect with utf8mb4 and exceptions turned on, put % inside LIKE values, generate placeholders for IN lists, bind LIMIT as an integer, use allow-lists for column names, and wrap related writes in transactions.

The PHP manual's page on prepared statements and stored procedures is short and worth reading. You can also see what I'm building on my projects page.

Originally published at mfaysal.com.