Image Slicing for Web: Sprites, Tiles, and Layouts

I was cleaning out an old hard drive last year and stumbled on a folder labeled “website_2006.” Inside was a PSD file with about forty slice guides crisscrossing a homepage layout. Every button, every nav tab, every decorative corner — all individually sliced and reassembled in a nested HTML table. I stared at it for a solid minute, partly horrified, partly nostalgic. That was how we built websites. And here’s the thing that surprised me: some of those same slicing techniques? They’re quietly useful again, just for completely different reasons.

Image slicing for the web didn’t die. It evolved. If you’re a developer or designer who thinks slicing ended with table-based layouts, you’re missing out on techniques that can genuinely improve performance, simplify responsive design, and solve problems that pure CSS still can’t handle gracefully. Let me walk you through where image slicing came from, where it went, and why it deserves a spot in your modern toolkit.

Remember When Every Website Was Sliced in Photoshop?

If you started building websites before about 2010, you probably remember the ritual. You’d design a full-page layout in Photoshop or Fireworks, then use the slice tool to carve it into dozens of rectangular pieces. Export the slices. Open Dreamweaver (or hand-code if you were feeling brave). Build a table. Drop each slice into its cell. Pray the table cells didn’t collapse in Internet Explorer 6.

It was tedious, fragile, and kind of brilliant for its time. CSS support was inconsistent across browsers, and there was no flexbox, no grid, no border-radius, no box-shadow. If your designer drew rounded corners, you sliced those corners into separate images and stuck them in table cells. Gradients? Sliced. Drop shadows? Sliced. That fancy navigation bar with the metallic texture? You better believe that was sliced into a dozen pieces.

The approach had real problems. Pages loaded slowly because every slice was a separate HTTP request — and in the early 2000s, browsers only opened two connections to a server at a time. A page with forty slices meant twenty round trips, sequentially. Maintenance was a nightmare. Changing a background color could mean re-exporting half the layout. Accessibility was awful because screen readers choked on tables-within-tables holding purely decorative image fragments.

When CSS matured enough to handle rounded corners, gradients, and flexible layouts natively, table-based slicing died almost overnight. Good riddance, honestly. But the underlying concept — splitting a large image into smaller, purpose-specific pieces — never went away. It just found better applications.

CSS Sprites: The Slicing Technique That Never Died

Here’s a question for you: if making forty HTTP requests for forty images was the original problem, what if you combined all those images into one file and only downloaded it once?

That’s the entire premise of CSS sprites, and it’s been a standard performance technique since at least 2004. You take all your icons, UI elements, button states, and small graphics, combine them into a single sprite sheet image, then use background-position in CSS to show just the portion you need for each element.

.icon {
  background-image: url('/images/sprite-sheet.png');
  background-repeat: no-repeat;
  width: 24px;
  height: 24px;
}

.icon-home {
  background-position: 0 0;
}

.icon-search {
  background-position: -24px 0;
}

.icon-settings {
  background-position: -48px 0;
}

Each class reveals a different 24x24 slice of the same image. One HTTP request, dozens of icons. The browser caches the sprite sheet, and every subsequent page load is essentially free.

“But wait,” you might be thinking, “don’t we have SVG icons and icon fonts now? Aren’t sprites obsolete?” Not quite. SVG icons are fantastic for simple, single-color iconography. But sprites still win in specific scenarios. Complex multi-color icons with gradients or photographic detail don’t translate well to SVG. Game development in the browser relies heavily on sprite sheets for character animations and tile maps. And if you’re building for environments where SVG support is limited — some email clients, older embedded browsers, certain IoT displays — PNG sprites remain the most reliable option.

The real trick with sprites is building the sheet efficiently. You want tight packing with minimal whitespace, consistent spacing between icons so your background-position math stays simple, and you want the file compressed well. That’s where an image splitter comes in handy in reverse — you can use it to verify your sprite dimensions, or to break apart someone else’s sprite sheet when you need to extract individual icons for modification. Our image grid splitting guide goes deeper on how to work with grid-based tile layouts for both sprites and other web assets.

Tiled Backgrounds and Repeating Patterns

Before CSS gradients existed, every textured background on the web was a tiny tiled image. And even now, some visual effects are genuinely easier to achieve with a tiled image than with pure CSS.

The concept is dead simple. You create a small image — sometimes as small as 1x1 pixel for a solid color overlay, but usually something like 200x200 pixels for a pattern — and let CSS repeat it across the element:

.textured-bg {
  background-image: url('/images/subtle-pattern.png');
  background-repeat: repeat;
}

.horizontal-stripe {
  background-image: url('/images/stripe-1px.png');
  background-repeat: repeat-x;
}

The magic is in creating seamless tiles. A seamless tile is an image where the left edge blends perfectly into the right edge, and the top blends into the bottom. When repeated, the seams disappear and you get what looks like one continuous surface. Creating these tiles by hand requires some Photoshop finesse — the classic technique involves using the Offset filter to push the seams to the center, then painting over them.

Where does slicing come into this? When you have a large texture — say, a photograph of marble, wood grain, or fabric — you need to extract the right section to create your tile. Slicing out a square from the most uniform region of a large texture gives you the best starting material. If you grab a section with obvious landmarks or strong directional features, the repetition will be painfully obvious. You want the most boring, uniform slice you can find. Counterintuitive, but that’s what tiles into an invisible pattern.

I still reach for tiled backgrounds when I need subtle paper textures, noise overlays, or geometric patterns. A 5 KB tiled PNG can create a full-screen texture that would be hundreds of kilobytes as a single large image. For texture-heavy designs — think restaurant sites, portfolio pages, or anything going for that handmade aesthetic — tiles remain one of the most efficient tools available.

Image Maps: Still Useful in Surprising Places

I know what you’re thinking. Image maps? Really? Those clunky <map> and <area> tags from the HTML 3.2 era?

Yes, really. Image maps got a bad reputation because they were massively overused in the late ’90s for navigation (every travel website had a clickable map of the United States, and none of them were accessible). But the core idea — defining clickable regions within a single image — is genuinely useful for specific types of content that haven’t gone away.

Architectural floor plans with clickable rooms that reveal details. Anatomical diagrams where clicking a body part shows medical information. Interactive campus maps. Product images where hovering over different components highlights specs. These all work naturally as image maps, and they work well.

The modern approach usually combines a sliced or annotated image with SVG overlays or absolutely positioned elements rather than using the raw <map> tag, which handles responsiveness poorly. You slice the base image to appropriate dimensions, overlay transparent interactive zones with CSS positioning, and get the same functionality with better accessibility and responsive behavior.

<div class="interactive-diagram" style="position: relative;">
  <img src="/images/engine-diagram.webp" alt="Engine diagram" width="1200" height="800">
  <a href="#cylinder" class="hotspot" style="position: absolute; top: 20%; left: 35%; width: 15%; height: 25%;"
     aria-label="Cylinder block">
    <span class="tooltip">Cylinder Block - 4 inline cylinders, aluminum alloy</span>
  </a>
</div>

The key insight is that slicing the base image into appropriate sizes for different viewport widths makes these interactive diagrams actually work on mobile. A 1200-pixel-wide engine diagram is useless on a 375-pixel phone screen — but if you slice a tighter crop of the most important region for mobile and serve it with the <picture> element, suddenly your interactive diagram works everywhere. Which brings us to the real modern use case for image slicing.

Responsive Image Slicing: Where the Old Art Gets New Life

This is where things get genuinely interesting for modern web development. Responsive image slicing isn’t about chopping images for table cells. It’s about serving fundamentally different image crops at different viewport widths — a technique called art direction.

Here’s the scenario. You’ve got a wide hero banner showing a team photo: eight people standing in a row with the company logo on the wall behind them. On desktop, it looks great at 1600x600. On a phone, that same image gets squeezed down to 375 pixels wide. Suddenly those eight people are tiny blobs. The logo is illegible. The impact is gone.

The naive solution is just letting the browser scale the image down. The smart solution is slicing different crops for different breakpoints:

<picture>
  <source media="(max-width: 480px)"
          srcset="/images/hero-mobile.webp"
          type="image/webp">
  <source media="(max-width: 1024px)"
          srcset="/images/hero-tablet.webp"
          type="image/webp">
  <img src="/images/hero-desktop.webp"
       alt="Team photo at company headquarters"
       width="1600" height="600">
</picture>

The mobile version might be a tight crop showing just three people. The tablet version shows five. Desktop shows the whole group. Same photo shoot, different slices, each optimized for its context. That’s art direction, and it’s the <picture> element’s entire reason for existing.

I’ve worked on projects where a single hero image had four different crops: a close-up portrait for small phones, a medium shot for large phones, a wider composition for tablets, and the full panoramic for desktop. The mobile crop was 60 KB. The desktop version was 180 KB. Without art direction, mobile users would’ve downloaded that 180 KB file and seen a version of it that looked terrible anyway. With slicing, they got a better-looking image that was a third of the size. Everyone won.

Preparing these crops used to mean opening Photoshop four times and manually selecting different regions. Today you can use BulkImagePro’s crop tool to quickly cut different regions from the same source image, then resize them to the exact pixel dimensions each breakpoint needs. It turns a fifteen-minute-per-image task into a two-minute one. If you’re doing this across dozens of images for a site redesign, our batch cropping guide covers how to set up efficient multi-image cropping workflows.

For a more comprehensive look at how responsive images work alongside format choices, our guide to image file formats for the web covers the format side of the equation.

Slicing Images for the Web with BulkImagePro

Whether you’re building a sprite sheet, cutting responsive crops, or splitting a large graphic into tiles, BulkImagePro’s image splitter handles the mechanical work so you can focus on the creative decisions.

Splitting Into a Grid

Open the split tool and upload your source image. Set the number of rows and columns. For a sprite sheet verification, you might split a 480x480 sheet into a 10x10 grid to confirm all your icons are properly aligned. For a responsive hero, split a wide source into the sections you want to crop differently for each breakpoint. The tool gives you a live preview showing exactly where the cuts fall, so you can adjust before committing.

Cropping for Art Direction

For responsive art direction, the crop tool is often more useful than the splitter. Upload your source hero image, set your target dimensions for mobile (say, 800x800 for a square close-up), position the crop region over the focal point, and export. Then do the same for tablet and desktop dimensions. You end up with three perfectly sized crops from one source image.

Converting and Compressing the Results

After slicing or cropping, you’ll want your images in a web-friendly format. Run them through the PNG to WebP converter or JPG to WebP converter to shave off another 25-35% in file size. Then compress them with the BulkImagePro compressor for the final optimization pass. The whole pipeline — slice, convert, compress — takes a fraction of the time it would in Photoshop, and everything runs in your browser without uploading files to a server.

Lazy Loading and Image Splitting: A Performance Trick Worth Knowing

Here’s a technique I don’t see discussed enough. For very large hero images — the kind that span the full viewport width and might be 300-500 KB even after compression — you can split the image into horizontal strips and lazy load the lower strips.

Think about it. When a user lands on your page, they see the top portion of the hero first. The bottom portion is partially or fully below the fold. If you split a 1600x800 hero into two 1600x400 strips, you can load the top strip immediately with fetchpriority="high" and lazy load the bottom strip. Your LCP improves because the browser only needs to download half the bytes for the above-the-fold content.

<div class="hero-composite">
  <img src="/images/hero-top.webp"
       alt="Mountain landscape panorama"
       width="1600" height="400"
       fetchpriority="high">
  <img src="/images/hero-bottom.webp"
       alt=""
       width="1600" height="400"
       loading="lazy"
       aria-hidden="true">
</div>

.hero-composite {
  display: flex;
  flex-direction: column;
  line-height: 0;
}

.hero-composite img {
  width: 100%;
  height: auto;
}

The line-height: 0 eliminates the tiny gap that inline images sometimes produce between them. The second image gets an empty alt and aria-hidden="true" because it’s a continuation of the first image, not a separate piece of content.

Is this technique worth the complexity for every project? No. But for pages where the hero image is a significant LCP bottleneck and you’ve already done all the standard optimizations — WebP conversion, proper sizing, CDN delivery, preloading — splitting the hero can squeeze out another measurable improvement. For more on how image optimization connects to Core Web Vitals, our deep dive into image compression and page speed covers the full picture.

When Slicing Helps and When It Hurts

Not every image benefits from being sliced. Here’s my honest take on the tradeoffs after years of applying these techniques.

Slicing Helps When…

You’re reducing initial payload. Splitting a hero image so the above-the-fold portion loads first is a legitimate performance win. Same logic applies to splitting long infographics so only the visible portion loads initially.

You need different crops for different screens. Art direction with the <picture> element is the correct solution for responsive images where a single crop doesn’t work at all viewport sizes. This isn’t optional — it’s responsive design done right.

You’re building sprite sheets. Combining many small images into one file still reduces HTTP overhead, even with HTTP/2 multiplexing. The caching benefit alone — one file to cache instead of forty — makes sprites worthwhile for icon-heavy interfaces.

You’re creating tiled patterns. A 10 KB tile that creates a full-screen texture will always outperform a 400 KB full-size background image. The math is obvious.

Slicing Hurts When…

You create too many pieces. Every slice is a separate file the browser has to request, decode, and render. HTTP/2 made parallel requests cheaper, but not free. Splitting an image into twenty strips for progressive loading is almost certainly worse than just compressing the original more aggressively.

The seams are visible. JPEG compression can produce slightly different artifacts on each side of a cut line. If you’re splitting a photograph and reassembling it visually, make sure the splits happen in regions where any slight mismatch won’t be noticeable — uniform sky, solid backgrounds, geometric patterns.

You’re adding complexity for marginal gains. If your hero image is already 80 KB after compression and WebP conversion, splitting it into two 40 KB strips adds code complexity for a savings that’s likely imperceptible to users. Optimize the big wins first. Refer to our complete guide to image splitting and cropping for a framework on when each technique is worth the effort.

You ignore the maintenance cost. Every slice means more files to manage, more markup to maintain, and more things that can break. If your team doesn’t have a process for regenerating slices when the source image changes, you’ll end up with mismatched pieces and mysterious visual bugs.

The Slicing Renaissance

Image slicing in 2026 looks nothing like it did in 2006. We’re not slicing rounded corners for table cells anymore. We’re slicing hero images for responsive art direction. We’re slicing textures into seamless tiles. We’re splitting icons into sprite sheets. We’re carving long-form graphics into lazy-loadable segments. And the same core splitting skills apply beyond the web — if you’re preparing images for social distribution, splitting images for Instagram carousels uses many of the same grid and dimension principles. The tools changed, the reasons changed, but the fundamental skill — knowing how and where to cut an image for the web — remains deeply practical.

The best part? You don’t need to futz with Photoshop guides and “Save for Web” dialogs anymore. BulkImagePro’s image splitter handles grid-based splits in seconds, the crop tool gives you precise art-directed cuts, and the compressor makes sure every slice is as lean as possible. No signup, no uploads to external servers, no limitations. Just fast, browser-based image slicing built for how we actually design websites today.

---

Frequently Asked Questions

What is image slicing in web design?

Image slicing is the practice of dividing a larger image into smaller pieces for use on a web page. Historically, this meant cutting a full-page design into table-cell-sized pieces. Today, it refers to techniques like creating CSS sprite sheets, slicing responsive image crops for different screen sizes, creating seamless tiled backgrounds, and splitting large images into segments for lazy loading.

Are CSS sprites still worth using in 2026?

Yes, in certain situations. While SVG icons have replaced sprites for simple single-color iconography, CSS sprites remain valuable for complex multi-color icons, browser game development, email templates where SVG support is limited, and any project that benefits from combining many small raster images into a single cached file. The caching benefit alone often justifies using a sprite sheet for icon-heavy interfaces.

How do I create a seamless tiled background image?

Start by slicing a square section from a large texture photograph, choosing the most uniform area you can find. In an image editor, use the Offset filter to shift the image so the seams move to the center. Paint over or clone-stamp the visible seams until they blend. Test by setting the image as a CSS background with background-repeat: repeat to verify the tile is truly seamless. The smaller the tile (100-300 pixels), the more efficient it is for web use.

What's the difference between image slicing and responsive images?

Standard responsive images use srcset to serve different sizes of the same image at the same crop. Image slicing for responsive design (called art direction) goes further by serving fundamentally different crops at different breakpoints using the HTML picture element. For example, a wide group photo on desktop might be sliced to a tight close-up of two people on mobile. Both techniques serve appropriate images per viewport, but art direction changes the composition itself.

Can splitting a hero image improve page load speed?

Yes. By splitting a large hero image into horizontal strips, you can load only the above-the-fold portion immediately and lazy load the rest. This reduces the initial payload and can improve your Largest Contentful Paint (LCP) score. The technique works best for tall hero images where a significant portion falls below the fold. For images that are already well-optimized and under 100 KB, the added complexity usually isn't worth the marginal improvement.

What tools can I use to slice images for the web?

BulkImagePro's image splitter handles grid-based splits directly in your browser with no software installation required. For art-directed responsive crops, the crop tool lets you cut specific regions from a source image at exact pixel dimensions. Both tools process images locally on your device, and you can compress the results with the BulkImagePro compressor before deploying to your site.