Updated: July 22, 2026
To compress portfolio images, first resize each image to the largest dimensions it will actually display — at the target device pixel ratio — then create responsive variants where needed, convert to WebP or AVIF with an appropriate fallback, and lower the quality setting until artifacts become just visible before stepping back one notch. Check edges, gradients, small text, and skin tones at 100% zoom before publishing. File-size figures should be treated as starting budgets rather than universal rules, because the right result depends on image detail, dimensions, format, and your page's performance targets. For confidential client work, verify the privacy model of any compression tool you use before uploading originals.
Key Takeaways
- Resize before you compress. Export at the largest display width multiplied by your target device pixel ratio. A large source file in a small display slot wastes bytes no compressor can fully recover.
- Deliver WebP or AVIF. Both are typically smaller than JPEG for photographic content. Use a
<picture>element to serve AVIF where supported with a WebP or JPEG fallback. - Push lossy compression to the artifact threshold. Lower quality until you can just see artifacts, then step back. That point is often well below maximum quality with no visible difference at normal viewing distance.
- Distinguish four separate optimizations. Resizing, format conversion, compression, and responsive delivery each solve a different problem; combining them in order produces the biggest gains.
- Match the tool to the privacy requirement. Use browser-local compression for confidential or unreleased work; server-side tools for public images.
Why Portfolio Image Size Affects Speed and Presentation
A design portfolio is often judged within the first few seconds of loading. If the hero image is slow to appear, it shapes a visitor's first impression of your work — and it also affects your page's measured loading performance.
The relevant metric is Largest Contentful Paint (LCP), one of Google's Core Web Vitals. LCP measures how long it takes for the largest visible element to render. On a portfolio, that element is often a large hero or project image. Core Web Vitals are one component of Google's page experience signals, which are among many factors that influence search performance — improving them may contribute to a better user experience and could improve rankings, but no specific outcome is guaranteed.
Cumulative Layout Shift (CLS) is also image-related: any image without explicit width and height attributes can push content around as it loads, creating a jarring experience. Compression alone does not fix CLS, but setting dimensions costs nothing and should accompany every image.
There is a second concern specific to designers: you work with confidential material. Unreleased brand work, client decks, and assets under NDA should not be uploaded to a random compressor's server without first understanding that tool's privacy practices.
Understanding the Four Optimizations
Before diving into steps, it helps to see what each operation actually does — because conflating them is the most common source of confusion.
| Operation | What it does | What it doesn't do |
|---|---|---|
| Resizing | Reduces pixel dimensions | Does not change codec or compression level |
| Format conversion | Changes codec (JPEG → WebP, AVIF) | Does not resize or guarantee quality |
| Lossy compression | Reduces file size by discarding data | Cannot recover discarded detail later |
| Responsive delivery | Sends different sizes to different viewports | Does not change the source file |
Doing them in the right order — resize, then convert, then compress — compounds the savings. Skipping the resize and compressing a 6000 px source to WebP is far less efficient than first exporting at the right display width.
How to Compress a Portfolio Image in Four Steps
This is the repeatable routine for a single image. Apply it to one representative image first, verify the result, then define export presets and batch-process the rest.
Step 1 — Resize to the actual display dimensions
Open the live page (or the design file) and read the CSS width of the image container. Multiply that by the device pixel ratios you want to support — commonly 1× and 2× — and generate a separate file for each. Add those as srcset candidates so the browser picks the appropriate version.
Cap large full-bleed heroes at the widest practical CSS width (check your design system), not at the source camera resolution. Exporting wider than the display slot buys no visible benefit.
Step 2 — Convert to a modern format
Export to WebP or AVIF. Both are typically meaningfully smaller than JPEG for photographic content, with WebP having broader browser coverage and AVIF often achieving lower file sizes at comparable visual quality. Current compatibility data is available at caniuse.com/webp and caniuse.com/avif — check those pages for up-to-date figures, as browser support continues to evolve.
Keep a JPEG fallback for clients and contexts that do not support either modern format.
Step 3 — Apply lossy compression at the artifact threshold
In your compression tool, lower the quality setting until you can just see degradation — ringing around hard edges, banding in gradients, or smearing in fine texture — at 100% zoom. Then move back one step. That setting is the artifact threshold for that image. It varies by image content, encoder, and quality scale, so verify visually for each type of image rather than applying a fixed number.
As a rough starting point (not a universal target):
- WebP: quality 75–82
- AVIF: quality 60–70
- JPEG fallback: quality 70–80
Quality scales differ between tools, and the same number in Squoosh is not the same as the same number in another encoder. Always validate visually.
Step 4 — Verify before publishing
See the dedicated verification section below. Do not publish until you have checked visual quality, file size, and page-level performance.
AVIF vs WebP vs JPEG: Which Format Should You Use?
| Format | Typical browser coverage | Relative size vs. JPEG | Best use |
|---|---|---|---|
| AVIF | Broad but not universal — check caniuse.com/avif | Often smaller, especially for photos | Primary format served via <picture> where supported |
| WebP | Very broad — check caniuse.com/webp | Often meaningfully smaller than JPEG | Safe primary or universal fallback; supports transparency and animation |
| JPEG | Universal | Baseline | Fallback for older clients; email; RSS |
| PNG | Universal | Larger than JPEG for photos | UI elements, logos, flat graphics with transparency |
| SVG | Universal | Vector (very small) | Logos, icons, line illustrations that must scale |
| JPEG XL | Limited — Firefox and Safari have added support, but major browsers vary; check caniuse.com/jpegxl | Varies | Not recommended as a sole delivery format without a fallback |
The robust delivery pattern uses a <picture> element so each browser takes the best format it supports:
<picture>
<source srcset="case-study.avif" type="image/avif">
<source srcset="case-study.webp" type="image/webp">
<img src="case-study.jpg" alt="Homepage redesign case study for Acme Corp"
width="1600" height="1000" loading="eager">
</picture>
Note: the alt text should describe what is actually depicted, not just label the image generically. The width and height attributes let the browser reserve space before the image loads, which helps prevent layout shift.
If you use an image CDN such as Cloudinary or imgix, check their documentation — some can negotiate format automatically from the browser's Accept header, which can remove the need for multiple <source> tags on your side.
What Dimensions Do Web Portfolio Images Need?
There is no universal pixel size that suits every portfolio. The right export width depends on the CSS container width, target device pixel ratio, and responsive breakpoints in your design. The table below lists starting points for common layout slots; treat them as examples, not standards.
| Portfolio element | Starting export width | Basis |
|---|---|---|
| Full-bleed hero / cover | 2000–2560 px | Covers common 2× desktop viewports; generate narrower srcset variants for mobile |
| Full project screenshot | 1600–2000 px | Roughly 2× a common desktop container |
| Gallery / case-study image | 1200–1600 px | — |
| Thumbnail / grid tile | 800–1200 px | — |
| Avatar / logo / icon | 400–800 px or SVG | Prefer SVG for anything vector |
These are starting budgets, not universal requirements. Adjust based on your specific CSS layout, device pixel ratio targets, and performance budget.
For responsive delivery, include a srcset so narrow viewports receive an appropriately sized file:
<img srcset="hero-800.webp 800w, hero-1600.webp 1600w, hero-2400.webp 2400w"
sizes="(max-width: 768px) 100vw, 1600px"
src="hero-1600.webp"
alt="Portfolio hero — brand identity project for Meridian"
width="2400" height="1200" loading="eager">
The sizes attribute must accurately reflect your actual CSS layout, not a guess. If it does not match, the browser may download a larger or smaller file than intended. Consult the MDN documentation on responsive images for a thorough explanation of how srcset and sizes interact.
Choose a Compression Tool by Privacy and Workflow
The most important distinction is where processing happens — in the browser on your device, or on a remote server. For confidential work, verify the tool's privacy policy before uploading anything.
| Tool | Where it runs | Key characteristics | Best for |
|---|---|---|---|
| Squoosh | Browser (local) | One image at a time; live split-view comparison; open source | Fine-tuning a single hero with visual control |
| TinyPNG | Server (upload) | Supports JPEG, PNG, WebP; check their site for current limits | Quick batches of public, non-sensitive images |
| ImageOptim | macOS app (local) | Lossless and lossy modes; strips metadata; free | Offline batch compression on macOS |
| ShortPixel | Server (upload) | WordPress plugin with auto-compression on upload; credit-based | CMS workflows where images are uploaded frequently |
| LessMB | Browser (local) | Free, no sign-up required; processes files in the browser | Quick browser-local compression when you want files to stay on your device |
| Cloudinary / imgix | CDN | Automatic format conversion and responsive delivery; see each provider's documentation for limits and privacy terms | At-scale delivery with format negotiation |
For confidential client work — unreleased brand identities, assets under NDA, anything you cannot risk on a third-party server — browser-local tools process images on your device. Verify the tool's behavior and privacy documentation before relying on this property for sensitive material.
How Far Can You Push Lossy Compression?
Further than most designers assume. Modern codecs are designed around human visual perception rather than pixel-exact accuracy, so they can remove significant data before the eye detects it.
The most reliable approach is the artifact threshold method:
- Open the original and compressed images side by side (Squoosh's split view is designed for this).
- Zoom to 100% in your browser or image viewer.
- Lower the quality setting until you can just see: ringing around sharp edges, banding in gradients, or smearing in fine texture.
- Step back one notch — that is your threshold for that image.
Results vary considerably by image content. A smooth photographic gradient compresses further before showing artifacts than a detailed architectural rendering with fine lines. For lossless work — small icons with crisp 1-pixel detail, or any image where a single artifact would be clearly wrong — use lossless compression instead.
One critical rule: compress from the master file, not from an already-compressed export. Re-compressing a JPEG or WebP accumulates degradation with each generation. Always go back to your source (Figma export, raw file, or uncompressed PSD) when you need to re-export.
A Test Record Template
If you do not have a controlled benchmark, use this template for each image type you optimize, so you have a record to refer back to:
Image: [filename or brief description]
Original format: [e.g. PNG from Figma export]
Original size: [px × px, file size in KB]
Output format: [e.g. WebP]
Quality setting: [e.g. 82]
Output size: [px × px, file size in KB]
Visual check: [Pass / Fail — note any artifacts observed at 100%]
Tool used: [e.g. Squoosh 1.x]
Date: [YYYY-MM-DD]
Keeping one record per asset type (hero, project screenshot, thumbnail) gives you a starting point for batch exports and makes it easy to revisit settings if you change tools.
How to Verify a Compressed Image
Compression is not done until you have checked three things:
Pre-publish verification checklist
- Visual check at 100% zoom. Compare original and compressed side by side. Inspect edges, text overlays, skin tones, and smooth gradients. Confirm no ringing, banding, or smearing.
- File size within budget. Note the output size and compare to your target budget. If it is over budget, revisit dimensions or format before lowering quality further.
- Explicit
widthandheightset. Every<img>element should declare its intrinsic dimensions or anaspect-ratio, so the browser reserves space before the image loads. -
alttext is descriptive. Describes the content or purpose of the image; not empty or generic. - LCP hero is not lazy-loaded. The first large visible image should use
loading="eager"(or noloadingattribute, which defaults to eager). Below-fold images should useloading="lazy". - Responsive
srcsetandsizesmatch the CSS layout. If using responsive delivery, thesizesvalue should reflect the actual rendered width. - Page-level check. Run the page through PageSpeed Insights after publishing and review Core Web Vitals (LCP, INP, CLS). Check the image-related audits for any remaining large payloads or format opportunities.
- Privacy verified. If the image was compressed with a server-side tool, confirm that was appropriate for the content.
If LCP remains slow after compression, common causes include: the hero image is still too large in dimensions, it is being lazy-loaded, or it lacks explicit dimensions causing layout recalculation.
Asset-Type Decision Table
Use this table to decide on format, sizing approach, and quality strategy for each type of portfolio asset. All values are starting points.
| Asset type | Recommended format | How to determine dimensions | Starting quality | Verify for |
|---|---|---|---|---|
| Full-bleed hero | AVIF (with WebP + JPEG fallback) | CSS container × target DPR; generate srcset variants | WebP 78–82 / AVIF 65–70 | Gradients, skin tone, hero text overlays |
| Project screenshot | WebP or AVIF with fallback | CSS container × target DPR | WebP 75–80 / AVIF 60–68 | Fine text, UI chrome, shadow edges |
| Gallery thumbnail | WebP with JPEG fallback | Thumbnail CSS slot × DPR | WebP 72–78 | Color accuracy, face clarity |
| Logo / icon | SVG (preferred); PNG if raster needed | Exact slot size or vector | Lossless | Crisp edges at all sizes |
| UI screenshot | WebP or PNG | CSS slot × DPR | WebP 78–82; PNG lossless for sharp UI | Text legibility, 1 px lines |
| Animated GIF replacement | WebP (animated) or <video> | Display slot | See tool docs | Motion smoothness, file size vs. video |
Quality scales are not directly comparable across tools. Validate visually — these numbers are a starting point, not a target.
Privacy Decision Table
| Asset sensitivity | Recommended approach |
|---|---|
| Public, already-released work | Any tool is appropriate; server-side tools add convenience |
| Unpublished personal work | Browser-local tools preferred; server-side acceptable if you have reviewed the privacy policy |
| Client work with NDA or confidentiality agreement | Browser-local tools; verify the tool's privacy documentation before use; do not upload to unknown third-party services |
| Work under active embargo | Browser-local tools only; consult your legal or NDA terms |
Common Mistakes That Affect Portfolio Images
Dimension and format mistakes
- Exporting at full camera or print resolution. A multi-thousand pixel source in a narrow CSS slot wastes bytes no compressor can recover.
- Serving one large image to all viewports without a
srcset— phones download the desktop hero unnecessarily. - Using PNG for full-color photographs — PNG is lossless and produces large files for photographic content where WebP or AVIF serves better.
- Skipping a JPEG fallback — some contexts (email, RSS, older browsers) still need it.
Loading and markup mistakes
- No
widthandheight— omitting these causes the browser to recalculate layout as images load, contributing to CLS. - Lazy-loading the LCP hero — the first large visible image should load eagerly so it does not delay LCP.
- Missing or generic
alttext — affects accessibility and search indexing.
Quality and metadata mistakes
- Re-compressing an already-compressed file (generation loss) — always compress from the master.
- Stripping copyright from your only copy — remove metadata from web delivery files, but keep it in a master archive.
- Forgetting animated content — an unoptimized animated GIF or autoplaying video can outweigh every still image on the page.
Recommended Settings by Portfolio Platform
Platform capabilities change; verify the current behavior in each platform's official help documentation before relying on automatic processing. The table below reflects general patterns and should be treated as a starting point for your own testing.
| Platform | General behavior to verify | What to do regardless |
|---|---|---|
| Webflow | May generate responsive variants — check Webflow's current asset help | Pre-compress at the right dimensions before upload; confirm output format |
| Squarespace | Adaptive sizing built in — check their media documentation | Still pre-compress originals; do not upload very large source files |
| Adobe Portfolio | Limited automatic processing — check Adobe Portfolio help | Compress and size everything before upload |
| Behance | Recompresses on upload — check Behance's image specs | Upload reasonably sized images; expect further platform compression |
| Framer | Responsive image handling — check Framer's image documentation | Pre-compress; confirm output format and dimensions in the published page |
| Self-hosted / custom | Whatever you implement | Use the <picture> AVIF → WebP → JPEG pattern, or an image CDN |
Next Steps
Follow this order to minimize rework:
- Pick one representative image (typically the homepage hero) and run through the full resize → convert → compress → verify workflow on that image alone.
- Run PageSpeed Insights on the page and note the LCP value and any image-related audits before you change anything else.
- Verify the result visually and in PageSpeed before touching the rest of the portfolio.
- Define export presets for each asset type (hero, project image, thumbnail) based on what you learned from the test image, so subsequent exports are consistent.
- Batch-process existing images from their masters — not from already-published or previously compressed versions.
- Set up responsive delivery using
srcsetandsizes(or a CDN or platform feature, if available), and add explicitwidthandheightto every image. - Add and verify
alttext on every image. - Re-run PageSpeed Insights after publishing changes and confirm LCP and CLS have improved.
For quick browser-local compression without uploading files — useful when testing settings on a single image — LessMB is one option worth bookmarking alongside your regular tools.
FAQ
Should I resize portfolio images before compressing them?
Yes. Resize first. Exporting a large source file for a narrow display container wastes far more bytes than any compressor can recover. Determine the largest display width the image will occupy, multiply by the target device pixel ratio (commonly 2 for high-DPI screens), then export at that size before applying compression.
What size should portfolio images be for the web?
There is no universal limit — the right size depends on the image's display slot, device pixel ratio, and visual complexity. As starting budgets (not guarantees), many designers target roughly 150–300 KB for a large hero image and under 100 KB for thumbnails. If a single image exceeds those budgets, revisit dimensions and format before lowering quality further.
Is AVIF or WebP better for a design portfolio?
Both are typically meaningfully smaller than JPEG for photographic content. WebP has broader browser coverage — check caniuse.com/webp for current figures. AVIF often achieves lower file sizes at comparable visual quality but has narrower support. The safest pattern is to serve AVIF first with a WebP or JPEG fallback inside a <picture> element.
How much can I compress images without losing quality?
Results vary by image content, format, and encoder. A reliable method is to lower the quality slider until you can just see artifacts at 100% zoom, then step back one notch. That threshold is often well below maximum quality with no visible difference at a normal viewing distance.
Will compressing images hurt my portfolio's SEO?
Done correctly, compression is unlikely to hurt SEO and may improve the loading experience. Smaller images can contribute to faster Largest Contentful Paint, one of several Core Web Vitals page experience signals. Compression only becomes a problem if it introduces visible artifacts or if you remove alt text, explicit dimensions, or responsive markup.
Should I compress images locally or upload them to a tool?
For client work, unreleased projects, or assets under NDA, consider using a tool that processes images locally in the browser so the originals do not leave your device. Review the tool's privacy documentation to confirm its local-processing behavior. Server-side tools are generally fine for public, already-released images.
Why does my compressed image look blurry or show banding?
The quality setting is likely too low for that image's content. Raise it until the artifact disappears, then fine-tune. Banding in gradients is common with AVIF at very low quality; ringing around hard edges is typical of aggressive JPEG or WebP compression. Always evaluate at 100% zoom, not in a scaled browser preview.