The fastest way to waste an hour on a blurry Facebook ad is to export the same design as a larger PNG, upload it again, and hope. That sometimes changes what you see. It does not tell you why the image looked soft—or whether the problem was ever in the uploaded file.
A sharp original can appear blurry because the image on screen is not necessarily the same file shown under the same conditions. The source may have been exported badly, submitted through an intermediary, cropped for a placement, resampled for a smaller resource, enlarged on a high-density display, viewed before it finished loading, or judged in a preview that is not the served placement.
The useful question is therefore not “What magic Facebook image size fixes blur?” It is:
At which first observable stage does the image stop looking sharp?
Find that transition, then change one relevant variable. The diagnostic order below helps you do that without treating PNG, a single pixel size, or repeated re-uploading as a universal cure.
First, Name the Surface That Looks Blurry
“Facebook ad image” can refer to several different images. Before touching the export, identify the exact surface and component.
| Where you see the problem | What it establishes | Best next check |
|---|---|---|
| The exported file on your computer | The problem exists before upload | Reopen the actual export at the intended display width; inspect dimensions, resampling and text size |
| A media-library thumbnail | Only that thumbnail or library view is soft | Open the placement-specific preview before changing the asset |
| The main Ads Manager preview | One preview surface is soft | Compare the relevant placement preview under the same zoom and load state |
| One placement preview | The problem may be placement-specific | Inspect the asset assigned to that placement and the crop actually shown |
| A product card or catalog item | The soft element may not be the main creative | Check the product-image source and synchronized catalog item |
| The page after the click | This is a landing-page image problem | Diagnose the website or commerce image pipeline, not the ad upload |
| An actual served impression | Delivery may be involved | Match the creative version, placement, device and capture time before testing a change |
| A moving ad | Video encoding is a different problem | Use a video-specific diagnostic process |
This first distinction prevents a common category error: replacing the main creative when the blurry element is actually a product image, link thumbnail or landing-page asset.
Follow the Image from Source to Screen
Treat the ad as a pipeline with seven checkpoints:
- Source or master. The editable design may contain a low-resolution product photo, enlarged screenshot, rasterized logo or tiny text even when the canvas itself is large.
- Export. The design tool creates a specific raster file with dimensions, format, color profile and encoder settings. A poor export can lose detail before Facebook sees it.
- Submitted asset. The file you selected may not be the file ultimately sent. A third-party uploader, catalog feed or automation layer can create a derivative.
- Placement treatment. A placement may use a crop, a placement-specific asset or another creative transformation. Cropping, resampling and encoding are separate operations.
- Loaded resource. A preview may initially show a lower-detail resource or an incomplete load.
- Display scaling. The resource is fitted into a CSS-sized box on a device with a particular pixel density and zoom level.
- Evidence surface. A library thumbnail, Ads Manager preview, shared preview and actual served impression are not interchangeable proof.
The task is to locate the earliest checkpoint where the appearance changes. If the local export already fails at the intended display width, there is no reason to begin with Facebook settings. If the local export is sharp and one placement alone is soft, the crop and placement assignment deserve attention before the file format does.
Processing can also occur before a file reaches a server. Meta’s historical 2019 engineering description of its Spectrum mobile image library discusses resizing, transcoding and conditional lossless JPEG crop or rotation in app-side image workflows. That is not documentation of today’s Ads Manager pipeline, but it is a useful warning against assuming that every change must have happened after upload.
Check the File That Was Actually Submitted
Start with a manual inventory. Record the filename, decoded pixel dimensions, file type, byte size and—when a team or automation tool is involved—a SHA-256 hash. Then record the route: direct Ads Manager upload, third-party uploader, API, catalog feed or reused media-library asset.
This matters because “my original is 4,000 pixels wide” may describe the design on a laptop, not the bytes that entered the ad workflow. One third-party provider, Ads Uploader, states in its 2026 Meta ads size guide that its own service can downsize certain high-resolution images and retry after an API rejection. That is the provider’s operational claim, not a universal Meta rule and not proof that the retry improves sharpness. It does show why the submitted derivative and retry log can be more useful than the master-file dimensions.
Catalog ads add another source branch. Shopify’s current Facebook and Instagram product-publishing documentation says product-image changes are made in Shopify and then synchronized to Facebook. For a catalog-sourced image, inspect the product item and its synchronized image URL; re-exporting a separate campaign design may change nothing.
A compact source record looks like this:
| Field | Example |
|---|---|
| Source route | Direct Ads Manager upload |
| Selected file | field-clock-4x5-v03.png |
| Decoded dimensions | 1440 × 1800 px |
| File size | 1,842,611 bytes |
| SHA-256 | Recorded locally before upload |
| Creative/version | Exact ad and revision ID |
| Placement under review | Exact placement, not “Facebook” generally |
Do not invent missing fields. “Unknown” is more useful than a confident diagnosis built on the wrong file.
Inspect the Export at the Size People Will See It
A file can be perfectly sharp at 100% zoom and still be unreadable in a feed-sized box. The reason is simple: canvas resolution and the proportion occupied by the message are different variables.
Consider an original teaching example. A 1,440-pixel-wide design contains fine text set at 32 pixels. It is displayed 360 CSS pixels wide:
32 × 360 / 1440 = 8 CSS pixels
Now double every dimension in the export. The canvas becomes 2,880 pixels wide and the same proportional text becomes 64 pixels:
64 × 360 / 2880 = 8 CSS pixels
The larger file supplies more source pixels, but the text still occupies the same share of the displayed ad. To make the text nominally twice as large at the same 360-pixel display width, change the design rather than merely scaling the export:
64 × 360 / 1440 = 16 CSS pixels
Eight or 16 CSS pixels here are not universal readability thresholds. The calculation simply tells you whether “more export pixels” changed the message’s effective size. Test the real typeface, weight, contrast and device at the actual intended width.
PNG Can Protect a Local Export, but It Cannot Promise a Sharp Served Ad
Format choice still matters—just at the correct stage. MDN’s image-format guide describes JPEG as lossy and notes that sharp diagrams, charts and text can show unsatisfactory artifacts; PNG uses lossless compression and is a sensible local choice for screenshots and flat graphics with text. A photographic creative may produce a practical JPEG with a smaller file.
That does not mean “PNG fixes Facebook blur.” A 2023 Adobe Community report described a square design exported as PNG-24 in sRGB that still looked poor to the author in a Facebook view, while another reader did not see the same problem. The case did not provide a matched paid-ad delivery record or a confirmed fix. Its useful lesson is to match viewing conditions, not to prescribe another format blindly.
Also ignore “300 DPI” as a web sharpness spell. Adobe’s resizing documentation explains that changing print resolution without resampling leaves the pixel dimensions unchanged. For this diagnosis, record pixel dimensions and the rendered size; PPI metadata alone does not add detail.
Separate Cropping from Resizing
A crop changes which source pixels remain. Resizing or resampling changes how many pixels represent the result. Encoding changes how those pixels are stored. Those operations can happen together, but they are not the same diagnosis.
Here is a deliberately simple placement-shape example. Suppose a 1,080 × 1,080 square is center-cropped to 4:5 while preserving its full 1,080-pixel height. The retained width is:
1080 × 4 / 5 = 864 pixels
That removes 108 pixels from each side and retains 80% of the original area. It does not create “20% blur.” It changes composition and leaves 864 source pixels to cover the displayed width.
Now suppose that crop is displayed 390 CSS pixels wide on a device with a device-pixel ratio of 3. The display has a nominal physical-pixel budget of:
390 × 3 = 1170 physical pixels
The ratio between display pixels and retained source width is approximately:
1170 / 864 = 1.35
A separate 4:5 asset that retains 1,080 pixels across the same field of view would yield approximately 1170 / 1080 = 1.08. These figures do not predict what Facebook’s renderer will do. They show why a placement crop can leave a smaller raster to cover the same screen area.
Use Meta’s live Ads Guide for the current recommendation and technical requirements of the exact format you are building. Do not turn the 1,080, 1,440 or 2,048 values in an old tutorial, a software example or this illustration into a universal Facebook limit.
Then inspect the actual placement preview. Is the intended subject still inside the crop? Is the soft element the same asset? Did a square source get enlarged after a narrow crop? A placement-specific problem calls for a placement-specific check, not a global re-export.
Match Browser, Device and Load Conditions
On the web, the rendered box is measured in CSS pixels while the display uses physical pixels. MDN defines devicePixelRatio as the ratio between the two. A 360-CSS-pixel image box on a DPR-3 display can therefore involve 1,080 physical pixels across. Page zoom can change the reported ratio; pinch zoom magnifies the page without changing CSS-pixel size in the same way.
This creates several false comparisons:
- one screenshot is viewed at 100%, while another is enlarged;
- two devices show different CSS widths;
- browser page zoom differs;
- one preview finished loading and another did not;
- a screenshot of the preview is compressed again in chat or email.
Meta documented progressive photo loading in its 2015 engineering post “Faster Photos in Facebook for iOS”: early progressive-JPEG scans contained less detail and were replaced as more data arrived. That historical News Feed photo mechanism is not proof that a current ad preview uses the same pipeline. It is a concrete reason to record load state before deciding that two captures represent the same resource.
For an ordinary check, note the device, app or browser version, page zoom, approximate rendered width and whether the image had finished loading. For a desktop technical investigation, Chrome’s Network panel documentation describes recording requests, previewing response bodies and capturing a timeline. Capture the original condition before disabling cache or changing the network. Review any exported diagnostic file for account IDs, URLs, tokens and personal data before sharing it.
Do Not Confuse a Preview with a Served Ad
Use an evidence ladder. The labels below are an editorial diagnostic model, not Meta terminology:
| Level | Evidence surface | What you may conclude |
|---|---|---|
| P0 | Local source/export | What your file looks like under the recorded local conditions |
| P1 | Media picker or library thumbnail | What that thumbnail looks like |
| P2 | Main Ads Manager preview | What that preview surface shows |
| P3 | Placement-specific or advanced preview | What the selected placement preview shows |
| P4 | Shared/mobile preview or Ad Library view | What that external preview surface shows |
| P5 | Matched served impression | What a real delivery looked like for the matched creative version, placement, device and time |
The practical rule is strict: without P5 evidence, do not call the problem preview-only. You can say two previews disagree. You cannot say the live ad is fine.
Public complaints illustrate why this matters, although they do not prove a platform bug. In a 2019 r/PPC post, the author reported trying a 5,500 × 3,667 original and 1,200 × 800 PNG and JPEG versions; the preview reportedly changed from sharp to softer, but the thread did not establish a served result. In a 2023 r/FacebookAds post, an author reported a 4,000 × 4,000 image that looked fine in preview and blurry after publication, but no matched original, creative ID and served image were available for verification.
These cases establish an expressed troubleshooting need, not a universal setting. A defensible record might read:
P2 appears soft. P3 appears sharp. P5 is absent. Allowed conclusion: the two preview surfaces disagree. Not allowed: the served ad is sharp, Facebook reproduced a bug, or re-uploading fixed it.
Use the Symptom to Choose One Next Check
| Observation | Next discriminating check | Do not conclude yet |
|---|---|---|
| Local export is soft at target width | Inspect source detail, export dimensions and resampling | Facebook compressed it |
| Whole image is sharp but fine text is weak | Calculate effective text size and make a typography variant | A larger proportional export will make the text larger |
| Local export is sharp; every preview is soft | Confirm the submitted asset, load state, rendered width and zoom | The master file reached the preview unchanged |
| Only one placement is soft or badly framed | Inspect its assigned asset and retained crop | One global pixel size is wrong |
| Only one device or browser differs | Match CSS width, DPR, zoom and load state | The platform served different quality |
| Main creative is sharp; product card is soft | Inspect catalog/product source and item URL | The main upload needs replacement |
| Preview is soft; matched served impression is sharp | Classify this record as preview-only for that matched case | All previews or future placements behave the same |
| Matched served impression is soft; local export is sharp | Run one controlled variant and preserve evidence | PNG, one setting or re-uploading is the cause |
| No matched served evidence exists | Keep delivery status unresolved | The ad is definitely fine or definitely broken |
Run a One-Variable Test, Not a Re-Upload Lottery
Once the diagnostic branch is narrow, choose the smallest comparison that answers it.
| Question | Change | Keep constant | What the result can answer |
|---|---|---|---|
| Is the local encoder harming text edges? | PNG versus JPEG | Master, crop, pixel dimensions, export app/version, placement and display | Whether format/encoder affected this matched pair |
| Is the available raster too small for the display? | 1080 × 1350 versus 1440 × 1800 | Design proportions, crop, format, placement and display | Whether more source samples changed this matched output |
| Is the placement crop the issue? | Square source cropped in-platform versus a pre-cropped 4:5 asset | Intended field of view, format and display | Whether the crop route changed the result; this is not a pure encoding test |
| Is the message simply too small? | 32-pixel versus 64-pixel type on the same 1440-pixel canvas | Images, format, placement and display | Whether a typography redesign improved readability |
| Is a relevant creative transformation involved? | One available option on versus off | Asset, crop, placement and every other setting | Whether that option changed this matched record |
Do not change format, dimensions, crop, typography and every automation setting in the same attempt. Even a sharper result would leave the cause unknown.
The local comparison supplied with this article is a completed example of the typography branch. Variant A uses a 1,440-pixel canvas and 32-pixel fine text. Variant B doubles canvas and text dimensions proportionally, so both still resolve to a nominal 8 CSS pixels at a 360-CSS-pixel display width. Variant C keeps the 1,440-pixel canvas but doubles the fine text, producing a nominal 16 CSS pixels. The files were built and rendered locally. They were not uploaded to Meta, and they say nothing about served-ad performance.
For a real account test, record:
- the actual source and submitted-file hash;
- export app/version, dimensions, format and byte size;
- creative/version and exact placement;
- upload and capture timestamps with timezone;
- preview level or matched served evidence;
- device, OS, app/browser, page zoom, rendered width and DPR when available;
- the single changed variable and everything held constant;
- the observation, the conclusion allowed and the alternative explanations still open.
The goal is a correctly rendered, readable image—not a promised improvement in click-through rate or return on ad spend. Image quality and campaign performance are different outcomes.
The Next Check Depends on the First Failed Stage
A blurry Facebook ad is not one problem. It is a symptom that can originate in the source, export, submitted derivative, placement geometry, load state, display scaling or evidence surface.
Start with the exact component and surface. Inspect the actual submitted file. Recreate the intended display width locally. Separate small-text geometry from whole-image softness. Measure the crop instead of treating it as compression. Match device and load conditions. Do not promote a preview into proof of delivery. Then change one variable.
That sequence will not make every image sharp. It will do something more valuable: tell you what the next check can prove—and stop you from “fixing” a stage that was never broken.
Sources
- Meta Ads Guide: Image, Meta, live placement-specific guide (sign-in may be required).
- Window: devicePixelRatio property, MDN Web Docs, last modified August 21, 2026.
- Image file type and format guide, MDN Web Docs, checked September 8, 2026.
- How resizing affects image resolution and pixel dimensions in Photoshop, Adobe, checked September 8, 2026.
- Open-sourcing Spectrum 1.0.0 for mobile image uploads, Engineering at Meta, January 17, 2019.
- Faster Photos in Facebook for iOS, Engineering at Meta, January 28, 2015.
- Publishing products on Facebook and Instagram by Meta, Shopify Help Center, checked September 8, 2026.
- Meta Ads Size Guide 2026, Ads Uploader, updated July 31, 2026; provider’s own operational description.
- Design uploaded low quality on Facebook, Adobe Community, April 20, 2023; user report.
- First time creating a Facebook Ad, the image I upload keeps rendering to a worse quality, Reddit r/PPC, June 29, 2019; user report.
- Ads look fine in preview but look blurry after publication, Reddit r/FacebookAds, December 6, 2023; user report.
- Network features reference, Chrome for Developers, updated July 16, 2024.
