DEV Community: Christopher H. Dutra

The 10-Minute Race: Designing Email Verification That Doesn't Frustrate Users

Christopher H. Dutra — Fri, 23 Oct 2026 10:33:05 +0000

You know the experience: you sign up, switch to your inbox, refresh twice, finally see the verification email... and discover the link has expired.

It's frustrating because the product is telling you to complete a task and then punishing you for not completing it quickly enough.

Email verification sits at the intersection of backend security, delivery delays, and interface design. You need all three parts to cooperate.

There are actually two clocks

If you use a short-lived mailbox during QA, you'll see this clearly:

Mailbox clock: how long the destination can receive and display messages.
Verification clock: how long your application's link or one-time code stays valid.

Those values are independent.

A message can still be visible after its verification token expires. Or the token could be valid while the temporary inbox that received it is already gone.

For example, 10 Minute Temp Email creates receive-only inboxes that expire after ten minutes.

That says nothing about the lifespan of tokens generated by your app.

Don't let the browser invent authority

A countdown makes a nice interface, but security must be enforced by the backend.

You might display the remaining time like this:

// For display only: the server remains authoritative.
const remainingMs = Math.max(0, expiresAt - Date.now());
const remainingSeconds = Math.ceil(remainingMs / 1000);

The actual verification endpoint still needs to check token validity on the server.

It should also decide what happens when the token has already been used.

Client time can be wrong, tabs can sleep, and network delays can shift what people see.

Design the resend flow before users need it

A good verification screen should answer a few basic questions:

Which address did we send the message to?
Can the user correct a typo?
When is it reasonable to request another message?
Will requesting a new email invalidate the previous link?
What happens if both messages arrive out of order?

The resend button should be visible, but not an invitation to flood inboxes.

Apply server-side rate limiting and show a clear cooldown if needed.

Most importantly, decide whether old tokens remain valid after a resend.

Either policy can be implemented, but the behavior should be intentional, tested, and documented.

The tests I would not skip

I like to run these scenarios in staging:

Verify immediately after signup.
Wait until the token expires, then click the link.
Request a resend and use the newest message.
Click a successful link a second time.
Change the email address during verification.
Delay email delivery and check the on-screen instructions.
Open the link on a different device, if your flow supports it.

For authorized manual tests, a temporary inbox helps make these loops repeatable without sending every attempt into a personal mailbox.

Keep the language human

A message like TOKEN_EXPIRED is useful in your logs. It isn't much help to a person who just wants to finish creating an account.

I'd rather show:

This verification link has expired. Request a new email to continue.

And after resending:

We sent a new link. Check your inbox, including spam or junk, and use the latest message.

Clear copy is a small feature that removes a surprising amount of support friction.

The broader lesson

Email verification shouldn't require perfect timing.

It should remain secure while giving ordinary users a reasonable path through delayed messages, mistyped addresses, and expired links.

Test the clock, test the email, and test the recovery experience. All three are part of the feature.

What's one thing you'd change about the last verification flow you built?

Temporary Email, Email Alias, or a Real Inbox? A Developer's Decision Guide

Christopher H. Dutra — Fri, 23 Oct 2026 10:25:27 +0000

I used to think the choice was simple: either use my main email address or use a fake one.

In reality, there are at least three useful categories, and they solve different problems: a permanent inbox, a forwarding alias, and a disposable inbox.

Mixing them up creates avoidable trouble—especially when an account that seemed temporary turns into one you actually care about.

Three tools, three jobs

Option	Best for	Can you come back later?
Permanent inbox	Work, important accounts, recovery	Yes, if you retain access
Email alias	Accounts you may keep, with address separation	Usually, while forwarding remains configured
Temporary inbox	One-time inbound messages and short authorized tests	No, once it expires

The key question isn't, "Which address hides me the most?"

It's "Will I need to receive another email at this address next month?"

If the answer is yes, a ten-minute inbox is probably the wrong option.

Scenario 1: Testing a signup flow

You're working on a staging environment, and every registration sends a confirmation link.

You need a fresh destination, you need to read the message once, and you can delete the test account afterwards.

A temporary receive-only inbox can be a nice fit, provided your staging application allows disposable domains.

A service like 10 Minute Temp Email creates an inbox without a permanent account and ends access after ten minutes.

That limited lifespan is useful precisely because the test doesn't need to become a new identity you maintain.

Scenario 2: Signing up for a tool you might keep

Maybe it's a design service, a monitoring dashboard, or a newsletter with an account you expect to use again.

An email alias is often smarter than a short-lived inbox.

Mail still reaches an address you control, and you can receive login codes, invoices, or recovery links in the future.

The alias also helps you understand which service sent a message or exposed an address, although it doesn't automatically make the entire account anonymous.

Scenario 3: Banking, employment, and important accounts

Use an address you can reliably access and recover.

This isn't an area to optimize for maximum disposability.

You may need statements, security alerts, legal notices, or a password-reset message months later.

A temporary address would turn a small privacy preference into a serious account-recovery risk.

What about spam protection?

Disposable mail can reduce how often your primary address is shared.

Aliases can help you compartmentalize services and disable a troublesome address without abandoning your primary inbox.

Neither stops all tracking, phishing, or misuse of information you enter elsewhere. Email is only one piece of your digital footprint.

And if a service rejects disposable domains, respect that rule. Don't treat the block as a puzzle to defeat.

My practical rule

Before entering an email address anywhere, ask:

Do I trust this service enough to maintain an account?
Will I need password recovery, receipts, or follow-up emails?
Is this a short-lived task where disposable mail is explicitly allowed?

If the account matters, use a durable address.

If it might matter later, use an alias.

If it's a truly disposable, low-stakes inbound task, use a short-lived inbox.

That simple distinction saves more headaches than any inbox-cleaning trick.

How do you organize email addresses for development tools and test accounts?

HTML Emails Are Untrusted Input. Your Inbox UI Should Treat Them That Way.

Christopher H. Dutra — Fri, 23 Oct 2026 10:24:12 +0000

Here's something easy to forget when building a web inbox: an email is not a page that you created.

It is content supplied by somebody else, possibly somebody who would very much like your application to behave badly.

That means showing an HTML email inside your app deserves roughly the same suspicion as rendering user-submitted HTML anywhere else.

A pretty preview can be a security problem

Email HTML can contain images, links, inline styles, and deeply nested markup.

Depending on how it is handled, it can also contain active elements or URLs you never intended to allow in your application.

Even if your mail parser works perfectly, the next step—turning parsed HTML into a browser view—is a separate trust boundary.

The dangerous shortcut is taking arbitrary message HTML and inserting it into the main application DOM as though it were trusted content.

Build layers instead of betting on one filter

A safer pipeline looks like this:

Incoming MIME
    |
    v
Parse message parts
    |
    v
Sanitize HTML and limit sizes
    |
    v
Store permitted content
    |
    v
Sanitize again for display
    |
    v
Render in an isolated viewer

Each step addresses a different concern.

Parsing turns the MIME envelope into understandable parts. Sanitizing removes dangerous markup and attributes. Size limits prevent absurdly large content from overwhelming the system.

An isolated viewer reduces the impact if something slips through.

This is defense in depth, not a guarantee that every email is safe.

Treat attributes and URLs as input, too

Stripping <script> tags alone doesn't solve the problem.

Event-handler attributes, unsupported embedded elements, and unsafe URL schemes also matter.

You also need to think about remote images.

An innocuous-looking email can load a remote resource when opened. That request may reveal information to the sender, even when no script runs.

A good viewer should make conscious decisions about remote content instead of treating every image URL as harmless.

Why plain text still matters

A developer can spend an hour perfecting an HTML verification template and forget its text alternative.

That's a mistake for accessibility, compatibility, and security-conscious readers.

A confirmation message should still explain what to do when styles or images are blocked.

For a signup email, I would check that the plain-text body contains the relevant explanation and a usable confirmation link or code.

A real implementation worth studying

10 Minute Temp Email has a receive-only web inbox.

Its published implementation notes describe server-side sanitization, a second browser-side pass with DOMPurify, and display inside a sandboxed iframe.

It also limits the attachment types that can be stored.

Those choices illustrate an important principle:

You don't have to trust the output of one layer just because that layer is yours.

The project goes into more detail in its email sanitization and deletion write-up.

Security isn't only about scripts

Even well-sanitized email can contain a convincing phishing message, a suspicious PDF, or a link to an attacker-controlled site.

The interface still needs clear sender information, understandable link behavior, and honest warnings where appropriate.

Security controls should make common mistakes less likely, not encourage people to click without thinking.

Final thought

The moment your application renders email, you've created a content-security feature whether you planned to or not.

Treat the message body as untrusted data, preserve the safe content users actually need, and isolate the reader from the rest of your application.

What has been your hardest HTML sanitization edge case?

A Disposable Inbox Is a Surprisingly Interesting Serverless Design Problem

Christopher H. Dutra — Fri, 23 Oct 2026 07:24:50 +0000

A temporary email address sounds almost too simple to be a software project: generate a random string, accept some email, show it in a browser, and delete everything ten minutes later.

Then you start asking questions.

Who is allowed to read the messages? What happens when mail arrives at the exact moment the inbox expires? Where do attachments live? How do you delete the underlying data instead of just hiding the UI?

Suddenly it's a neat little systems-design exercise.

Start with a constraint: receive-only

The first architectural decision I would make is not to build a miniature Gmail.

A receive-only service needs to accept and display inbound messages. It doesn't need compose, reply, forwarding, or outbound SMTP.

Every extra feature introduces operational and abuse risks that the core use case doesn't need.

That's how 10 Minute Temp Email is designed: it handles short-lived inbound messages, but doesn't let users send or reply.

Split mail processing from the website

One useful real-world reference is the site's published Cloudflare architecture:

Browser
   |
   v
Web Worker ------> D1: metadata
   |
   v
Inbox UI

Email Routing
   |
   v
Mail Ingest Worker
   |
   +-------------> D1: metadata
   |
   +-------------> R2: message bodies

The web side creates a mailbox and exposes authenticated read/delete operations.

The ingest Worker receives incoming mail through Cloudflare Email Routing, checks that the address is valid, parses the message, and stores the permitted content.

Separating those responsibilities makes the design easier to reason about. A normal page request should never have to process a raw MIME message.

Expiration has to be enforced by the server

A countdown in JavaScript is useful feedback, but it is not your security boundary.

If the browser says an inbox has expired, your API must still reject further reads.

If a message is delivered to an expired address, the ingest side must not quietly accept it just because the browser is no longer watching.

A reasonable data model keeps an expires_at timestamp for each mailbox.

Every read and ingest operation checks that timestamp against server time. A scheduled cleanup process then removes database records and stored message objects.

This distinction matters: access expiration and physical cleanup are related, but not the same operation.

Your session is the mailbox key

Making the generated email address the only secret would be a mistake.

Addresses are visible to the services that send mail and could appear in logs.

The safer pattern is to bind a mailbox to a browser session.

In this example project, an HttpOnly cookie proves ownership, while an HMAC hash of the session token is stored in D1.

That way, knowing someone's temporary address isn't enough to open their inbox.

It's also why opening the same email address in a different browser won't magically give you access to its messages.

The failure paths are the interesting part

Think about these cases before writing the happy-path UI:

An email arrives seconds after expiration.
The object store succeeds, but the database insert fails.
The same message is delivered twice.
Someone guesses random inbox addresses.
A user tries to download an attachment from another session.

A robust implementation needs consistent checks, rollback or compensating cleanup, deduplication, and authorization on every attachment fetch.

The useful takeaway

Tiny products can contain serious engineering lessons.

A ten-minute inbox combines event-driven processing, ephemeral storage, authentication, cleanup, and untrusted content handling in a compact system.

If you're curious about the exact components used by this particular service, its creator has documented the receive-only inbox architecture.

If you were building one, which part would you prototype first: ingest, session security, or expiration?

How I Test Email Verification Without Filling My Personal Inbox

Christopher H. Dutra — Fri, 23 Oct 2026 07:23:41 +0000

There's a small but surprisingly annoying part of building signup flows: the emails.

The form looks fine. The database row exists. Your mail provider says the message was accepted. Then someone tries to register and discovers that the verification link is broken, the message arrived too late, or the resend button creates two valid codes.

I've learned to treat email verification as its own feature, not as the final line of a signup ticket.

A clean inbox makes repeated testing easier

For a quick manual check, I don't want to create a new permanent mailbox or keep adding +test1, +test2, and +test3 to my personal address.

Those aliases can be useful, but eventually the inbox becomes a graveyard of test emails.

A short-lived inbox is a reasonable option when I'm testing an app I own or am authorized to test, and the app permits disposable addresses.

For example, 10 Minute Temp Email provides a receive-only inbox that lives for ten minutes, needs no account, and cannot recover old mail after it expires.

It's not a replacement for a real mailbox or a mail-deliverability testing platform. It's simply useful for watching one test message arrive.

The five-minute happy-path test

Here's a small manual workflow I like:

Open the temporary inbox before submitting the signup form.
Copy the generated address instead of typing it by hand.
Submit the form on the staging site.
Check that the message arrives, and read both its subject and body.
Open the verification link. Confirm that the correct account becomes verified.
Open the link again. It should not perform a second verification action.
Delete the test account and inbox when finished.

That catches a lot more than checking whether an email-send function returned success.

What I deliberately try to break

The happy path is only the beginning. These are the cases I add before I consider the feature ready:

Test	What should happen
Wrong or altered token	Clear failure without revealing sensitive details
Expired token	Friendly explanation and a safe resend path
Reused verification link	No repeated side effect
Resend requested twice	Predictable handling of old and new tokens
Delayed message	UI explains what the user can do next
Different browser	Behavior matches the app's session requirements
HTML blocked or stripped	Plain-text email still contains the essential action

One especially useful check is clicking the link after the app's token expires. A mailbox's lifetime and your application's token lifetime are two different clocks.

A small testing rule that pays off

Keep the test environment unmistakably separate from production. Prefix subjects with [STAGING], avoid real customer data, and use accounts you can safely delete.

Also, don't use a temporary mailbox to test whether messages land in Gmail's Primary tab or Outlook's junk folder. For that, you need real destination mailboxes and proper deliverability checks.

The lesson

A signup feature isn't finished when the server sends the email. It's finished when someone receives it, understands it, uses it successfully, and can recover from ordinary mistakes.

A throwaway inbox helps make that last mile less tedious.

For a more detailed checklist, the temporary inbox signup-testing guide is a useful companion.

What's the strangest email-verification bug you've had to debug?

QR Codes Are More Useful Than You Think: Practical Ideas for Developers

Christopher H. Dutra — Fri, 23 Oct 2026 06:57:44 +0000

QR codes have been around for years, but they continue to appear in interesting places.

Restaurant menus, WiFi networks, event tickets, product packaging, business cards, and even authentication workflows.

From a developer's perspective, they're interesting because they provide a simple bridge between physical objects and digital experiences.

Someone points a phone camera at a small square image, and suddenly they're visiting a website, opening an application, or accessing information.

But there's a little more to QR codes than just converting a URL into black-and-white squares.

Let's explore some useful applications and practical implementation details.

What actually happens when you scan a QR code?

A QR code is a two-dimensional barcode that stores encoded data.

The scanner reads its pattern and interprets the stored content.

That content might be a website URL, a piece of text, a WiFi configuration, or contact information.

An important distinction is that QR codes don't necessarily need an internet connection to be decoded.

For example, a QR code containing plain text can be read locally.

A QR code containing a website URL, however, generally requires a connection to access that website.

Understanding the difference helps when deciding how to use QR codes in your applications.

1. Sharing website links

Let's start with the most common use case.

You have a website:

https://example.com

You generate a QR code containing that URL.

When someone scans the code, their phone recognizes the link and offers to open it.

Simple.

But there are a few details worth considering.

First, keep your URLs reasonably short.

Longer URLs require more encoded data, which can produce denser QR codes.

Dense codes may be more difficult to scan when printed at small sizes.

Second, think about the destination.

If the website isn't mobile-friendly, making access easier with a QR code won't create a good user experience.

A QR code is only the entry point.

The experience after scanning matters just as much.

2. WiFi QR codes

This is one of my favorite practical applications.

Instead of telling someone a long WiFi password, you can let them scan a QR code.

A commonly used WiFi QR payload looks like this:

WIFI:T:WPA;S:GuestNetwork;P:examplePassword;;

Here's what the main parts represent:

T identifies the security type.
S identifies the network name.
P contains the password.

Compatible phones can recognize this format and offer to connect to the network.

It's useful for offices, meeting rooms, guest houses, and other places where visitors frequently need WiFi access.

Just remember that anyone who can scan or decode the QR code may also recover the password.

For public areas, use an appropriately isolated guest network rather than exposing credentials for your main internal network.

3. Contact cards and business details

QR codes can also store contact information.

One approach is to encode a vCard.

For example:

BEGIN:VCARD
VERSION:3.0
FN:Alex Smith
ORG:Example Studio
TEL:+15550101234
EMAIL:alex@example.com
END:VCARD

A compatible scanning application can interpret that information as contact details.

Instead of manually typing someone's phone number and email address, a person can scan the code and save the contact.

For business cards, conference badges, and networking events, this can be genuinely useful.

It also reduces typing mistakes.

4. Generating QR codes with JavaScript

You don't always need an external service to create QR codes.

There are JavaScript libraries that generate QR codes directly inside applications.

For example, using the qrcode npm package:

npm install qrcode

You can generate an image like this:

import QRCode from "qrcode";

const url = "https://example.com";

const qrImage = await QRCode.toDataURL(url, {
  errorCorrectionLevel: "H",
  margin: 2,
  width: 300,
});

console.log(qrImage);

The returned data URL can be used as the source of an image element.

For a production application, you could generate QR codes for tickets, user profiles, or other resources.

One practical security note: if you're generating QR codes for authentication or access control, never rely on the QR image itself as proof of authorization. Use secure tokens, expiration rules, and server-side validation.

5. Creating QR codes with logos

You've probably noticed QR codes that contain a company logo in the center.

They look more branded, but adding a logo also introduces an interesting technical problem.

The logo covers part of the QR code.

How can the code still work?

QR codes support error correction, which allows a scanner to recover data even when some parts are damaged or obscured.

Common error-correction levels are:

Level	Approximate recovery capacity
L	7%
M	15%
Q	25%
H	30%

These are approximate recovery capacities, not guarantees that a logo can safely cover that percentage of the image.

Logo placement, contrast, code density, and scanning conditions all matter.

For branded QR codes, a higher error-correction level is often useful.

Still, always test the final code on more than one device.

A QR code that looks attractive but fails to scan isn't doing its job.

Creating QR codes without writing code

If you're building QR generation directly into an application, using a JavaScript library makes sense.

But sometimes you only need a QR code for a presentation, website, event poster, or printed card.

Writing code for a one-time image export would be unnecessary.

That's where a browser-based generator is convenient.

ImgTask's QR Code Generator supports URLs, text, WiFi configurations, email, phone numbers, SMS, and vCard information.

You can customize colors, adjust error correction, add a logo, and export the result as PNG or SVG.

The generation happens inside the browser, without uploading the content or logo to ImgTask's server.

SVG is particularly useful when you want a scalable QR image for print or larger designs.

A few mistakes worth avoiding

Even though QR codes are simple to generate, there are some common issues.

Using poor contrast: Light-colored modules on a busy background may be difficult to scan.

Removing too much whitespace: QR codes need a clear quiet zone around the pattern.

Making them too small: A QR code on a poster should be large enough to scan comfortably from the intended distance.

Using unnecessarily long URLs: More encoded data often means a denser pattern.

Skipping real-world testing: A code that scans perfectly on your monitor might behave differently when printed.

My preference is to generate the code, test it on two different phones, and then check the final design before using it publicly.

Final thoughts

QR codes aren't complicated technology, but they're surprisingly flexible.

They can help connect websites with physical products, simplify WiFi sharing, distribute contact information, and improve event workflows.

For developers, the interesting part is deciding where QR codes actually improve an experience.

Not every feature needs a QR code.

But when scanning removes unnecessary steps for the user, it can be a genuinely useful addition.

What's the most interesting way you've used QR codes in one of your applications?

One Logo, Multiple Icon Sizes: Preparing App Icons for Android and iOS

Christopher H. Dutra — Fri, 23 Oct 2026 06:55:36 +0000

Building a mobile application involves dozens of small tasks beyond writing code.

Authentication, navigation, APIs, notifications, permissions, and testing usually get most of our attention.

Then, as the application gets closer to release, we remember something else.

We need the app icons.

Not just one icon, either.

Android and iOS have different requirements, and preparing the necessary image files can become surprisingly repetitive.

Let's look at how app icons work and how to simplify the process.

Why can't we just use one PNG?

Imagine you've designed a beautiful 1024 × 1024 pixel logo for your application.

It looks great.

So why can't you just add that PNG to your project and let the operating system handle everything?

Technically, platforms and development tools can resize images. But mobile application projects typically expect assets organized according to platform-specific conventions.

Android supports different screen densities and uses resources such as mipmap-mdpi, mipmap-hdpi, and others.

iOS projects commonly use an asset catalog containing an AppIcon image set.

Providing appropriately sized assets helps ensure that your application icon looks consistent across supported devices.

It also makes the project easier to manage.

Understanding Android icon sizes

Android traditionally organizes launcher icon resources by screen density.

A common set of launcher icon sizes looks like this:

Density	Icon size
mdpi	48 × 48
hdpi	72 × 72
xhdpi	96 × 96
xxhdpi	144 × 144
xxxhdpi	192 × 192

A typical Android resource directory might look like:

app/src/main/res/
├── mipmap-mdpi/
│   └── ic_launcher.png
├── mipmap-hdpi/
│   └── ic_launcher.png
├── mipmap-xhdpi/
│   └── ic_launcher.png
├── mipmap-xxhdpi/
│   └── ic_launcher.png
└── mipmap-xxxhdpi/
    └── ic_launcher.png

In the Android manifest, the application may reference the icon like this:

<application
    android:icon="@mipmap/ic_launcher"
    android:label="@string/app_name">
</application>

Of course, modern Android applications also commonly use adaptive icons.

Adaptive icons have separate foreground and background layers, allowing Android launchers to apply different masks and shapes.

A simple collection of PNG files doesn't automatically replace a correctly configured adaptive icon.

For modern Android applications, developers should review adaptive icon requirements as well.

What about iOS?

Apple uses its own asset catalog system.

In an Xcode project, you'll commonly encounter a directory named:

AppIcon.appiconset

This contains icon assets and a Contents.json file describing how those assets correspond to the relevant icon slots.

Rather than manually referencing each icon in code, Xcode uses the asset catalog configuration.

For App Store distribution, a 1024 × 1024 pixel icon is important.

One detail to remember: the App Store icon should not contain transparency. If you're starting with a transparent logo, prepare a version with an appropriate opaque background.

The platform handles the final icon presentation, including corner treatment.

Preparing a good source image

Before generating all the required sizes, focus on the original design.

Ideally, start with a high-resolution square image.

For example, 1024 × 1024 pixels is a useful starting point.

Here are a few practical design considerations.

Keep it simple. A detailed illustration may look great at full resolution but become difficult to recognize on a home screen.

Leave some breathing room. Avoid placing important visual elements too close to the edges, where platform-specific masking may affect them.

Think about contrast. The icon should remain recognizable against a variety of wallpapers and interface themes.

Test at small sizes. Don't make design decisions using only the large original image.

These considerations matter more than squeezing extra visual detail into the icon.

Generating the files without repetitive resizing

You can prepare all these assets using design software or platform-specific development tools.

Android Studio, for example, includes Image Asset Studio for creating icons.

But when you're working across multiple projects, a straightforward icon generator can save manual work.

One option is the ImgTask App Icon Pack Generator.

You upload a square logo, and it creates a downloadable ZIP containing Android launcher PNG sizes and an iOS AppIcon.appiconset directory.

The generated package includes Android mipmap folders, a Play Store icon, and iOS icon assets with a Contents.json file.

Image processing happens locally in the browser.

For a standard raster icon workflow, this can reduce the time spent preparing repetitive asset sizes.

You should still review the exported assets and make any platform-specific adjustments required by your application.

A simple release checklist

Before publishing your mobile application, check that:

Your source logo is high resolution.
The Android launcher icon looks sharp at different densities.
Adaptive icons are configured if required.
The iOS asset catalog contains the expected icon sizes.
The App Store icon satisfies Apple's current requirements.
The icon remains recognizable at small sizes.
You've tested the icon on actual devices or emulators.

Also make sure your application's icon visually matches its store listing and brand identity.

Consistency matters.

Final thoughts

Generating mobile app icons isn't particularly complicated, but it can be a repetitive part of the development process.

Once you've built a few mobile applications, you start appreciating small workflow improvements.

Whether you use Android Studio, Xcode, a design tool, or an online generator, the underlying goal is the same.

Start with a good source image, prepare the assets correctly, and test the final icon where users will actually see it.

A great app deserves an icon that feels just as polished.

How do you handle app icon generation in your projects? Do you use platform-specific tools or generate the assets separately?

The Small Website Detail Developers Often Forget: Favicons

Christopher H. Dutra — Fri, 23 Oct 2026 06:52:08 +0000

There's a particular moment in website development that feels familiar.

The layout is finished. The contact form works. The mobile design looks good. You've connected the domain and deployed everything.

Then you open the website in another browser tab.

And there it is.

A generic browser icon sitting next to your beautifully designed website's name.

You forgot the favicon.

It's a tiny detail, but it's one of those finishing touches that makes a website feel complete.

The interesting part is that creating a proper favicon setup involves a little more than just uploading one image.

What exactly is a favicon?

A favicon is the small icon associated with a website.

You'll commonly see it in browser tabs, bookmarks, browser history, and certain shortcut interfaces.

Its main purpose is recognition.

When someone has fifteen tabs open, a recognizable favicon can make it easier to find your website.

It also reinforces visual consistency between your website, logo, and overall brand.

The favicon may only occupy a few pixels, but those pixels are visible in places where your full logo isn't.

Why uploading a random logo isn't ideal

Suppose your company has a beautiful horizontal logo with a company name and an illustration.

You upload it as a favicon.

The browser reduces it to 16 × 16 pixels.

Suddenly, the text is unreadable, the illustration is blurry, and the whole thing becomes a tiny collection of shapes.

That's why favicons should be designed for small display sizes.

A good favicon often uses a simplified version of a logo.

For example, instead of using your entire brand name, consider using its symbol or an easily recognizable initial.

The goal isn't to fit everything inside a square.

It's to make the brand recognizable at a very small size.

Which favicon sizes do you actually need?

A useful basic favicon package includes:

File	Purpose
`favicon.ico`	Traditional browser compatibility
`favicon-16x16.png`	Small browser icons
`favicon-32x32.png`	Higher-resolution browser icons
`apple-touch-icon.png`	Apple home-screen bookmarks

The traditional ICO format can contain multiple image sizes inside one file.

A common combination is 16 × 16, 32 × 32, and 48 × 48 pixels.

For Apple touch icons, 180 × 180 pixels is a widely used size.

You don't necessarily need dozens of icon files for every project.

A small, well-organized set is usually enough for a basic website.

Adding favicon files to HTML

Once you've generated the files, place them somewhere publicly accessible on your website.

For a typical static website, that might look like this:

public/
├── favicon.ico
├── favicon-16x16.png
├── favicon-32x32.png
└── apple-touch-icon.png

Then reference them inside the HTML <head>:

<link
  rel="icon"
  href="/favicon.ico"
  sizes="any"
>

<link
  rel="icon"
  type="image/png"
  sizes="32x32"
  href="/favicon-32x32.png"
>

<link
  rel="icon"
  type="image/png"
  sizes="16x16"
  href="/favicon-16x16.png"
>

<link
  rel="apple-touch-icon"
  sizes="180x180"
  href="/apple-touch-icon.png"
>

The browser can select an appropriate supported resource.

You can use the same approach in frameworks such as Astro, React-based static sites, and other projects that expose public assets.

The exact folder structure depends on the framework.

What about generating the favicon files?

You can manually resize a logo, export several PNG files, and create an ICO file using image-editing software.

But if you do this regularly for client websites, the repetitive export work becomes a little annoying.

That's why tools that create a favicon package from a single image are useful.

For example, ImgTask's Favicon Generator takes one image and generates a ZIP containing a multi-size favicon.ico, small PNG favicons, and an Apple touch icon.

The conversion runs in the browser, without uploading the logo to a server for processing.

It's a convenient option when you already have a square logo and just need the correct files for deployment.

Why isn't my new favicon showing up?

This is another common problem.

You replace the favicon, refresh the website, and the old icon is still there.

Sometimes the issue isn't your HTML.

Browsers can cache favicon files aggressively.

Before changing your entire favicon configuration, check a few things.

First, try opening the favicon file directly in the browser.

For example:

https://example.com/favicon.ico

Make sure it returns the icon you expect.

Then check the browser's developer tools to confirm the asset is loading successfully.

You can also try a fresh browser profile or a private browsing window.

If caching continues to cause problems, changing the asset filename or versioning its URL can help.

For example:

<link
  rel="icon"
  href="/favicon.ico?v=2"
>

Depending on your hosting or CDN configuration, you may also need to invalidate cached files.

A few design tips

When preparing your favicon, keep these things in mind:

Start with a square image.
Use a simple, recognizable symbol.
Avoid tiny text and complicated illustrations.
Check how the icon looks against light and dark browser themes.
Test it at 16 × 16 pixels, not just at its original resolution.

That last point is important.

An icon that looks beautiful at 512 pixels can become unreadable when displayed at 16 pixels.

Always inspect the final result at the actual size your users will see.

Final thoughts

Favicons aren't the most exciting part of building a website.

Nobody is going to choose a website because its favicon is amazing.

But missing or poorly designed favicons can make an otherwise polished project feel unfinished.

And since creating a proper favicon set takes very little time, there's really no reason to skip it.

The next time you're preparing a website for launch, add the favicon check to your deployment checklist.

What's the most commonly forgotten small detail in your web development projects?

JPEG vs WebP: What Developers Should Know Before Converting Website Images

Christopher H. Dutra — Fri, 23 Oct 2026 06:46:45 +0000

When building websites, we spend plenty of time choosing frameworks, optimizing JavaScript, and improving database queries.

But there's another decision that can affect website performance: the image format.

JPEG has been around for decades, and it still works well. However, newer formats such as WebP give developers more options when balancing file size and visual quality.

So should we convert every JPEG image to WebP?

Not necessarily.

Let's explore when it makes sense and when it doesn't.

Why JPEG is still everywhere

JPEG is one of the most widely supported image formats.

It works across browsers, operating systems, image editors, and countless older applications.

For photographs, JPEG remains a perfectly reasonable choice.

But JPEG compression has limitations.

At aggressive compression settings, images can develop noticeable artifacts, particularly around text, edges, and detailed areas.

Modern formats offer different compression techniques that may achieve better results.

What makes WebP different?

WebP is an image format developed by Google.

It supports lossy and lossless compression, along with transparency and animation.

One of its biggest advantages is that photographic images can often be stored in smaller files than equivalent-looking JPEGs.

For example, you might have a JPEG photograph that's several hundred kilobytes.

After converting it to WebP, the result may become noticeably smaller while still looking similar.

However, this isn't guaranteed.

The savings depend on the image content, original compression, and conversion settings.

An already optimized JPEG might not benefit much from conversion.

How does this affect actual website performance?

Suppose you're building an e-commerce product page.

The page contains twelve product photographs.

If each image is unnecessarily large, the total image payload can quickly become significant.

Reducing the weight of those assets means fewer bytes need to travel over the network.

That can help with loading performance, particularly on slower connections.

But file size isn't the only performance factor. Image dimensions, network conditions, decoding time, caching, and loading priority matter too.

WebP is useful, but it's not a substitute for a complete optimization strategy.

Serving WebP with a JPEG fallback

Modern browsers support WebP, but keeping a JPEG fallback can still make sense for legacy environments and certain workflows.

The HTML <picture> element allows you to provide alternative formats:

<picture>
  <source
    srcset="/images/product.webp"
    type="image/webp"
  >

  <img
    src="/images/product.jpg"
    alt="Wireless keyboard on a desk"
    width="800"
    height="600"
  >
</picture>

A browser that supports WebP can use the WebP source.

If WebP isn't supported, the JPEG image remains available.

This is particularly useful when compatibility with older browsing environments is a requirement.

For modern applications without those compatibility requirements, using WebP directly may be sufficient.

Converting existing JPEG assets

You don't always need to change your application's code to prepare WebP files.

For a Node.js build pipeline, the Sharp library is one option.

Here's a small example:

import sharp from "sharp";

await sharp("product.jpg")
  .webp({ quality: 80 })
  .toFile("product.webp");

console.log("Image converted.");

This reads an image, converts it to WebP with a specified quality setting, and writes the output file.

For a larger project, you could extend this to process an entire assets directory.

But sometimes you just want to convert five or ten images manually.

In those situations, I like the simplicity of a browser-based converter.

ImgTask's JPG to WebP Converter allows you to select JPEG images, adjust the output quality, and download the converted files.

It also supports multiple image uploads, and the conversion happens locally in the browser rather than uploading the files for server-side processing.

It's a convenient alternative when setting up a full image-processing pipeline would be unnecessary.

Be careful with repeated conversions

Here's something worth remembering.

JPEG uses lossy compression.

If you convert a JPEG to lossy WebP, you're compressing data that has already been compressed.

That means conversion cannot magically recover details lost in the original JPEG.

Repeated conversions can introduce additional degradation.

Whenever possible, generate your final image formats from a high-quality original.

For example:

Original high-quality image
          |
          |
   ----------------
   |              |
 JPEG output    WebP output

This is generally better than:

Original → JPEG → WebP → JPEG → WebP

The second workflow introduces unnecessary recompression.

When should you keep JPEG?

Despite WebP's advantages, JPEG still makes sense in several situations.

Some external platforms and older applications expect JPEG uploads.

Printing workflows may require specific image formats or color-management handling.

You might also be working with an existing image pipeline that already generates well-optimized JPEGs.

And sometimes the actual file-size difference is so small that conversion provides little practical benefit.

Choose a format based on your project's needs rather than simply choosing the newest option.

A practical workflow

For most modern websites, I'd suggest this approach:

Keep a high-quality original image.
Resize it to the dimensions your interface needs.
Generate a WebP version.
Compare quality and file size against JPEG.
Test the image in its actual page layout.
Keep a JPEG alternative where compatibility matters.

You don't have to convert everything at once.

Start with the largest images on your most important pages and measure the results.

Final thoughts

WebP isn't a magic solution for slow websites, but it is a useful tool.

When combined with sensible dimensions, responsive images, and good loading strategies, it can help make pages lighter.

The goal isn't to use the most modern image format everywhere.

The goal is to deliver images that look good without transferring unnecessary data.

That's a much better way to think about image optimization.

Are you using WebP, AVIF, or traditional JPEGs in your current projects?

Why Image Optimization Should Be Part of Every Developer's Workflow

Christopher H. Dutra — Fri, 23 Oct 2026 06:43:49 +0000

Why Image Optimization Should Be Part of Every Developer's Workflow

You can build a beautiful website, write clean code, use a modern framework, and still end up with a painfully slow page.

Sometimes the problem isn't JavaScript, your database, or your hosting provider. It's a handful of images that nobody thought to optimize.

Images are one of those things that seem harmless during development. You download a photo, add it to your project, and move on. Everything looks fine locally.

Then you check the website on a slower mobile connection, and suddenly those beautiful images become a performance problem.

Let's talk about a few practical ways to avoid that.

The problem with unoptimized images

Imagine you're building a landing page for a business.

You have a hero image, three service images, a few customer photos, and some decorative graphics.

Individually, none of them seems particularly large. But imagine each photo is 2–4 MB.

Now a visitor might download more than 10 MB of images just to view one page.

That's a lot of unnecessary data, particularly for someone on a mobile connection.

The interesting part is that you can often reduce image file sizes significantly without making them look noticeably worse.

And you don't necessarily need an expensive image editor to do it.

Compression and resizing are different things

These two concepts are often confused.

Image compression reduces the number of bytes required to store an image. Depending on the format, this might involve removing redundant data or discarding some visual detail.

Image resizing changes the image's pixel dimensions.

For example, suppose you have a 4000 × 3000 pixel photograph.

You can compress that photograph while keeping its original dimensions.

But if your website displays it at only 800 pixels wide, you should probably resize it too.

A practical workflow is:

Determine the dimensions your interface actually needs.
Resize the source image if necessary.
Choose an appropriate output format.
Compress the image.
Compare its visual quality with the original.

It's a simple process, but it can make a meaningful difference.

Choosing the right image format

Not every image should be treated the same way.

JPEG remains useful for photographs, especially when compatibility matters.

PNG is excellent for graphics that need transparency or lossless detail, such as certain screenshots and logos.

WebP is a good option for modern websites because it often produces smaller files than JPEG or PNG at comparable visual quality.

AVIF can deliver excellent compression too, although encoding support, performance, and compatibility with your particular workflow should be considered.

There's no universal winner.

For a website with many photographic images, I'd usually start by testing WebP. For simple graphics where exact pixels matter, PNG may still be preferable.

Let the browser do less work

Optimizing image files is only one part of the process.

Consider this HTML:

<img
  src="/images/product.webp"
  alt="Product displayed on a wooden desk"
  width="800"
  height="600"
  loading="lazy"
  decoding="async"
>

A few small details matter here.

The width and height attributes help the browser reserve layout space, reducing unexpected movement as the image loads.

loading="lazy" delays loading images that aren't immediately needed.

And decoding="async" allows image decoding without necessarily blocking other rendering work.

One important exception: don't automatically lazy-load your main hero image or Largest Contentful Paint (LCP) image. That image usually needs to load early.

A small tool that makes image preparation easier

When working on websites, it's useful to have an easy way to prepare images without opening a full design application.

That's one of the reasons we built ImgTask's Image Compressor.

It supports multiple image formats, lets you adjust compression quality, and offers an optional target file size.

You can also compare the original and compressed versions before downloading.

One feature I particularly appreciate is that image compression happens in the browser. The images aren't uploaded to ImgTask's server for processing.

It's useful when preparing client website assets or handling images you'd prefer to keep on your device.

Of course, for large automated production pipelines, tools such as Sharp or build-time image processing are more appropriate.

But for manually preparing a handful of assets, a browser-based tool is convenient.

Don't forget responsive images

Another common problem is serving the same large image to every device.

A phone with a narrow screen usually doesn't need the same file dimensions as a large desktop monitor.

HTML provides a straightforward solution:

<img
  src="/images/banner-800.webp"
  srcset="
    /images/banner-400.webp 400w,
    /images/banner-800.webp 800w,
    /images/banner-1200.webp 1200w
  "
  sizes="(max-width: 600px) 100vw, 800px"
  alt="Website banner"
  width="800"
  height="450"
>

With srcset and sizes, the browser can select a suitable resource based on the layout and device.

Just remember that all the referenced image sizes need to exist.

My practical image optimization checklist

Before publishing a website, I think it's worth checking:

Are any images significantly larger than their displayed dimensions?
Have photographic assets been compressed appropriately?
Would WebP or AVIF make sense for the project?
Do images have meaningful alternative text?
Are width and height attributes provided?
Are below-the-fold images lazy-loaded?
Have important images been tested on slower connections?

These aren't complicated optimizations. They're small habits that add up.

Final thoughts

It's easy to get excited about frameworks, new libraries, and complicated performance techniques.

But sometimes the most useful improvement is much simpler.

Take a look at the images your website is sending to visitors.

Resize what doesn't need to be huge, compress what can be smaller, and serve formats appropriate for the situation.

Your users shouldn't have to download several megabytes of unnecessary data just to read a page.

And if you want a quick way to prepare assets manually, the ImgTask Image Compressor is one option.

What's your preferred approach to image optimization? Do you handle it during development, at build time, or through an image CDN?