DEV Community: Fox leo

A pre-upload image dimension checklist for social and website assets

Fox leo — Wed, 29 Jul 2026 02:26:12 +0000

Image upload bugs often look like platform bugs:

the YouTube thumbnail looks soft,
the LinkedIn banner crops the logo,
the Open Graph preview shows the wrong shape,
the Instagram cover frame hides the title,
or a marketplace image gets rejected.

In practice, many of these issues start with the exported file. The design may look correct in Figma, Canva, Photoshop, or a mobile editor, but the final file can still have the wrong pixel dimensions, ratio, format, or compression.

This is the checklist I use before publishing a visual asset.

1. Check the exported file, not the design canvas

Do not assume the design canvas and the downloaded image are identical.

Export settings, compression tools, CMS uploads, screenshots, and file sharing apps can change the real image. Before uploading, confirm:

width,
height,
aspect ratio,
file size,
image format,
and whether the file is portrait, landscape, square, or wide.

For this first check, use ImageSizeKit's browser-based image checker:

https://imagesizekit.com/image-dimension-checker/

The point is not only to read the dimensions. The point is to decide which publishing path the image belongs to.

2. Match the image to a real destination

An image that is "large enough" can still be wrong for the surface.

Examples:

1280 x 720 usually fits a 16:9 thumbnail workflow.
1080 x 1920 is a vertical-cover workflow.
1200 x 630 is usually an Open Graph or link preview workflow.
a very wide image is more likely a banner or profile header workflow.

Once the checker gives you the raw facts, route the file to the right next check.

3. Use a second check for platform behavior

Dimension checks answer: "What is this file?"

Platform checks answer: "Will this file survive the destination?"

That second question includes crop behavior, small-screen readability, safe areas, compression, and upload limits.

Useful next routes:

YouTube thumbnail check: https://imagesizekit.com/youtube-thumbnail-size/
Social media image check: https://imagesizekit.com/social-media-image-checker/
Banner and cover check: https://imagesizekit.com/banner-size-checker/
Open Graph preview check: https://imagesizekit.com/open-graph-preview-checker/

4. Do not reuse one export everywhere

One master design can create multiple final exports. One final export should not usually be used everywhere.

For example, a wide hero image might be adapted into:

a YouTube thumbnail,
a LinkedIn banner,
an Open Graph preview,
a blog cover,
and a vertical social cover.

Those are different files, even if they come from the same design system.

5. Final pre-upload checklist

Before publishing an important image, check:

The final file's pixel dimensions.
The aspect ratio.
The destination platform.
Whether text stays readable at feed size.
Whether key content is away from risky crop edges.
File size and format.
Whether a separate export is needed for another platform.

This takes a minute and prevents a surprisingly large number of upload, preview, and crop issues.

ImageSizeKit is an independent tool library for image size checks and publishing references. It is not affiliated with YouTube, Instagram, LinkedIn, Facebook, or Open Graph platforms.

A pre-upload image dimension checklist for social and website assets

Fox leo — Wed, 29 Jul 2026 02:18:24 +0000

Image upload bugs often look like platform bugs:

the YouTube thumbnail looks soft,
the LinkedIn banner crops the logo,
the Open Graph preview shows the wrong shape,
the Instagram cover frame hides the title,
or a marketplace image gets rejected.

This is the checklist I use before publishing a visual asset.

1. Check the exported file, not the design canvas

Do not assume the design canvas and the downloaded image are identical.

Export settings, compression tools, CMS uploads, screenshots, and file sharing apps can change the real image. Before uploading, confirm:

width,
height,
aspect ratio,
file size,
image format,
and whether the file is portrait, landscape, square, or wide.

For this first check, use ImageSizeKit's browser-based image checker:

https://imagesizekit.com/image-dimension-checker/

The point is not only to read the dimensions. The point is to decide which publishing path the image belongs to.

2. Match the image to a real destination

An image that is "large enough" can still be wrong for the surface.

Examples:

1280 x 720 usually fits a 16:9 thumbnail workflow.
1080 x 1920 is a vertical-cover workflow.
1200 x 630 is usually an Open Graph or link preview workflow.
a very wide image is more likely a banner or profile header workflow.

Once the checker gives you the raw facts, route the file to the right next check.

3. Use a second check for platform behavior

Dimension checks answer: "What is this file?"

Platform checks answer: "Will this file survive the destination?"

That second question includes crop behavior, small-screen readability, safe areas, compression, and upload limits.

Useful next routes:

YouTube thumbnail check: https://imagesizekit.com/youtube-thumbnail-size/
Social media image check: https://imagesizekit.com/social-media-image-checker/
Banner and cover check: https://imagesizekit.com/banner-size-checker/
Open Graph preview check: https://imagesizekit.com/open-graph-preview-checker/

4. Do not reuse one export everywhere

One master design can create multiple final exports. One final export should not usually be used everywhere.

For example, a wide hero image might be adapted into:

a YouTube thumbnail,
a LinkedIn banner,
an Open Graph preview,
a blog cover,
and a vertical social cover.

Those are different files, even if they come from the same design system.

5. Final pre-upload checklist

Before publishing an important image, check:

The final file's pixel dimensions.
The aspect ratio.
The destination platform.
Whether text stays readable at feed size.
Whether key content is away from risky crop edges.
File size and format.
Whether a separate export is needed for another platform.

This takes a minute and prevents a surprisingly large number of upload, preview, and crop issues.

ImageSizeKit is an independent tool library for image size checks and publishing references. It is not affiliated with YouTube, Instagram, LinkedIn, Facebook, or Open Graph platforms.

How to check banner image size before publishing a profile header or channel cover

Fox leo — Wed, 29 Jul 2026 00:54:15 +0000

Banner images are easy to get wrong because they are wide, reused often, and cropped differently by different platforms.

A banner can pass a simple pixel check and still fail in production:

the profile photo covers the logo,
the channel banner title is outside the safe area,
the mobile crop cuts off the call to action,
the image is wide enough but too short,
or the same export is reused for LinkedIn, YouTube, Facebook, and a website hero without checking each placement.

This is a simple workflow for catching those issues before upload.

1. Start with the final exported image

Check the exported file, not only the design template.

A template name like "LinkedIn banner" or "YouTube channel art" is not proof that the final file still matches that size. Exports can be resized, compressed, or downloaded at a different scale.

Use ImageSizeKit's Banner Size Checker:

https://imagesizekit.com/banner-size-checker/

It helps route wide images toward the right platform workflow instead of treating every wide rectangle as interchangeable.

2. Separate dimension fit from crop safety

Banner checks have two layers.

First, the image needs the right basic shape:

width,
height,
aspect ratio,
and enough resolution for the surface.

Second, the important content needs to sit in a safe area.

That second layer matters because banners are shown inside different containers: desktop header, mobile header, search preview, profile page, channel page, app view, and sometimes embedded cards.

3. Use platform-specific guidance after the broad check

If the file is meant for a YouTube channel, check the YouTube banner guide and safe-area reference:

If the file is meant for LinkedIn, check the LinkedIn banner guide:

https://imagesizekit.com/linkedin-banner-size/

If the file is meant for Facebook, check the cover photo guide:

https://imagesizekit.com/facebook-cover-photo-size/

If the file is really a website link preview, it may not be a banner at all. Use the Open Graph workflow instead:

https://imagesizekit.com/open-graph-preview-checker/

4. Design for the smallest real view

Banner images are usually designed on a large screen and judged later on mobile.

Before publishing, zoom out and check whether the key content still works when the image is narrow or cropped.

Keep these elements away from dangerous edges:

logo,
headline,
face,
product screenshot,
key date,
call to action,
QR code,
or any text that must be read.

5. Final banner upload checklist

Before upload, confirm:

The checked file is the final export.
The dimensions match the intended platform.
The aspect ratio is close to the target surface.
Important content is inside the safe visual area.
Text is readable on mobile.
The banner is not being reused blindly across multiple platforms.
A separate export exists for each major crop.

A wide image is not automatically a safe banner. Check the file first, then check the platform crop.

ImageSizeKit is an independent image size checker and guide library. It is not affiliated with YouTube, LinkedIn, Facebook, or other platforms mentioned here.

How to Check Social Media Image Sizes Before Publishing

Fox leo — Fri, 24 Jul 2026 23:56:12 +0000

Most social image mistakes are not design mistakes. They are export and crop mistakes.

The image looks clean in Canva, Figma, Photoshop, or a mobile editor. Then it goes live and something changes: an Instagram Reel cover crops the title, a LinkedIn banner hides the headline behind the profile photo, a Facebook cover looks different on desktop and mobile, a YouTube banner loses important text, or a website link preview uses the wrong Open Graph image.

Before redesigning the artwork, check the exported image file itself.

The pre-upload workflow

Use this sequence before publishing:

Export the final image from your design tool.
Check the real pixel width and height of the exported file.
Check the aspect ratio.
Check the file format and file size.
Match the image to the publishing surface.
Check crop-sensitive areas before uploading.
Re-export separate versions when one image cannot fit every surface.

The important habit is simple: check the downloaded file, not only the design canvas.

A quick size reference

There is no single best social media image size. The right size depends on where the image will be displayed.

Surface	Common target	Main risk
Instagram Reel cover	Vertical 9:16	Title or face too close to UI areas
LinkedIn profile banner	Wide horizontal	Profile photo and mobile crop hide text
Facebook cover	Wide horizontal	Desktop and mobile crops differ
YouTube channel banner	Wide with safe area	Text outside the center safe area disappears
Open Graph image	Usually around 1.91:1	Link preview crops small text or uses an old cached image
Product or marketplace image	Often square or high resolution	Too-small source image looks soft in previews

For a broader platform-by-platform reference, start with this social media image sizes guide:

https://imagesizekit.com/social-media-image-sizes/

Check the local file first

If you already exported the image, start by checking the file locally:

https://imagesizekit.com/social-media-image-checker/

This answers the basic questions first:

What is the real width?
What is the real height?
What is the aspect ratio?
What file type did I export?
Is this file closer to a feed image, banner, link preview, or product image workflow?

For sensitive drafts, browser-side checks are useful because the image does not need to be uploaded just to read basic dimensions.

Treat banners as their own workflow

Banner images are easy to get wrong because matching the canvas size is not enough. A banner can be technically wide enough and still fail if the important content sits near a crop-prone edge.

For social headers, profile banners, and cover images, use a banner-specific check:

https://imagesizekit.com/banner-size-checker/

Then compare the result with the surface-specific guide you need, such as LinkedIn banner size or YouTube banner safe area.

The practical rule: keep identity, headline, logo, and call-to-action content near the stable center area.

Treat Open Graph images as website assets

Open Graph images are not just social images. They are website metadata assets.

A practical default for many web pages is 1200 x 630 pixels, about a 1.91:1 ratio. But the file can still fail if the source image is too small, the ratio is off, text is too close to the edges, the page still points to an old og:image, or a social platform has cached the previous preview.

For the size guide, use:

https://imagesizekit.com/open-graph-image-size/

For the preview-oriented check, use:

https://imagesizekit.com/open-graph-preview-checker/

After the image file looks right, update the page metadata and refresh the relevant platform preview cache.

My final checklist

Before publishing, I check:

Does the exported file match the intended surface?
Is the width and height large enough for a sharp preview?
Is the aspect ratio close to the target surface?
Is important text away from crop-prone edges?
Is the file size reasonable for the platform?
Am I forcing one image into surfaces that need different crops?
Did I update website metadata when the image is for a link preview?

If one image has to work across feed, banner, and link preview contexts, I usually export separate versions. It takes a few extra minutes and prevents avoidable publishing issues.

ImageSizeKit is an independent browser-based image size checker and guide library. It is not affiliated with Instagram, Facebook, LinkedIn, YouTube, Shopify, Etsy, or Open Graph platforms.

The fastest publishing habit is boring but effective: check the exported file before upload.

How to Check Social Media Image Sizes Before Publishing

Fox leo — Fri, 24 Jul 2026 12:16:28 +0000

Most social image mistakes are not design mistakes. They are export and crop mistakes.

Before redesigning the artwork, check the exported image file itself.

The pre-upload workflow

Use this sequence before publishing:

Export the final image from your design tool.
Check the real pixel width and height of the exported file.
Check the aspect ratio.
Check the file format and file size.
Match the image to the publishing surface.
Check crop-sensitive areas before uploading.
Re-export separate versions when one image cannot fit every surface.

The important habit is simple: check the downloaded file, not only the design canvas.

A quick size reference

There is no single best social media image size. The right size depends on where the image will be displayed.

Surface	Common target	Main risk
Instagram Reel cover	Vertical 9:16	Title or face too close to UI areas
LinkedIn profile banner	Wide horizontal	Profile photo and mobile crop hide text
Facebook cover	Wide horizontal	Desktop and mobile crops differ
YouTube channel banner	Wide with safe area	Text outside the center safe area disappears
Open Graph image	Usually around 1.91:1	Link preview crops small text or uses an old cached image
Product or marketplace image	Often square or high resolution	Too-small source image looks soft in previews

For a broader platform-by-platform reference, start with this social media image sizes guide:

https://imagesizekit.com/social-media-image-sizes/

Check the local file first

If you already exported the image, start by checking the file locally:

https://imagesizekit.com/social-media-image-checker/

This answers the basic questions first:

What is the real width?
What is the real height?
What is the aspect ratio?
What file type did I export?
Is this file closer to a feed image, banner, link preview, or product image workflow?

For sensitive drafts, browser-side checks are useful because the image does not need to be uploaded just to read basic dimensions.

Treat banners as their own workflow

Banner images are easy to get wrong because matching the canvas size is not enough. A banner can be technically wide enough and still fail if the important content sits near a crop-prone edge.

For social headers, profile banners, and cover images, use a banner-specific check:

https://imagesizekit.com/banner-size-checker/

Then compare the result with the surface-specific guide you need, such as LinkedIn banner size or YouTube banner safe area.

The practical rule: keep identity, headline, logo, and call-to-action content near the stable center area.

Treat Open Graph images as website assets

Open Graph images are not just social images. They are website metadata assets.

For the size guide, use:

https://imagesizekit.com/open-graph-image-size/

For the preview-oriented check, use:

https://imagesizekit.com/open-graph-preview-checker/

After the image file looks right, update the page metadata and refresh the relevant platform preview cache.

My final checklist

Before publishing, I check:

Does the exported file match the intended surface?
Is the width and height large enough for a sharp preview?
Is the aspect ratio close to the target surface?
Is important text away from crop-prone edges?
Is the file size reasonable for the platform?
Am I forcing one image into surfaces that need different crops?
Did I update website metadata when the image is for a link preview?

If one image has to work across feed, banner, and link preview contexts, I usually export separate versions. It takes a few extra minutes and prevents avoidable publishing issues.

ImageSizeKit is an independent browser-based image size checker and guide library. It is not affiliated with Instagram, Facebook, LinkedIn, YouTube, Shopify, Etsy, or Open Graph platforms.

The fastest publishing habit is boring but effective: check the exported file before upload.

How to Check Social Media Image Sizes Before Publishing

Fox leo — Thu, 16 Jul 2026 05:46:33 +0000

Most social image mistakes are not design mistakes. They are export and crop mistakes.

Before redesigning the artwork, check the exported image file itself.

The pre-upload workflow

Use this sequence before publishing:

Export the final image from your design tool.
Check the real pixel width and height of the exported file.
Check the aspect ratio.
Check the file format and file size.
Match the image to the publishing surface.
Check crop-sensitive areas before uploading.
Re-export separate versions when one image cannot fit every surface.

The important habit is simple: check the downloaded file, not only the design canvas.

A quick size reference

There is no single best social media image size. The right size depends on where the image will be displayed.

Surface	Common target	Main risk
Instagram Reel cover	Vertical 9:16	Title or face too close to UI areas
LinkedIn profile banner	Wide horizontal	Profile photo and mobile crop hide text
Facebook cover	Wide horizontal	Desktop and mobile crops differ
YouTube channel banner	Wide with safe area	Text outside the center safe area disappears
Open Graph image	Usually around 1.91:1	Link preview crops small text or uses an old cached image
Product or marketplace image	Often square or high resolution	Too-small source image looks soft in previews

For a broader platform-by-platform reference, start with this social media image sizes guide:

https://imagesizekit.com/social-media-image-sizes/

Check the local file first

If you already exported the image, start by checking the file locally:

https://imagesizekit.com/social-media-image-checker/

This answers the basic questions first:

What is the real width?
What is the real height?
What is the aspect ratio?
What file type did I export?
Is this file closer to a feed image, banner, link preview, or product image workflow?

For sensitive drafts, browser-side checks are useful because the image does not need to be uploaded just to read basic dimensions.

Treat banners as their own workflow

Banner images are easy to get wrong because matching the canvas size is not enough. A banner can be technically wide enough and still fail if the important content sits near a crop-prone edge.

For social headers, profile banners, and cover images, use a banner-specific check:

https://imagesizekit.com/banner-size-checker/

Then compare the result with the surface-specific guide you need, such as LinkedIn banner size or YouTube banner safe area.

The practical rule: keep identity, headline, logo, and call-to-action content near the stable center area.

Treat Open Graph images as website assets

Open Graph images are not just social images. They are website metadata assets.

A practical default for many web pages is 1200 x 630 pixels, about a 1.91:1 ratio. But the file can still fail if the source image is too small, the ratio is off, text is too close to the edges, the page still points to an old Open Graph image, or a social platform has cached the previous preview.

For the size guide, use:

https://imagesizekit.com/open-graph-image-size/

For the preview-oriented check, use:

https://imagesizekit.com/open-graph-preview-checker/

After the image file looks right, update the page metadata and refresh the relevant platform preview cache.

My final checklist

Before publishing, I check:

Does the exported file match the intended surface?
Is the width and height large enough for a sharp preview?
Is the aspect ratio close to the target surface?
Is important text away from crop-prone edges?
Is the file size reasonable for the platform?
Am I forcing one image into surfaces that need different crops?
Did I update website metadata when the image is for a link preview?

If one image has to work across feed, banner, and link preview contexts, I usually export separate versions. It takes a few extra minutes and prevents avoidable publishing issues.

ImageSizeKit is an independent browser-based image size checker and guide library. It is not affiliated with Instagram, Facebook, LinkedIn, YouTube, Shopify, Etsy, or Open Graph platforms.

The fastest publishing habit is boring but effective: check the exported file before upload.

How I write product-safe AI image prompts for ecommerce

Fox leo — Wed, 15 Jul 2026 22:41:42 +0000

AI image prompts for ecommerce should not start with style.

They should start with product truth.

The failure mode I worry about is not an ugly image. It is a polished image that quietly changes what the buyer thinks they will receive.

A label gets rewritten. A logo shifts. A material becomes glossier. The product looks bigger than it is. A fake rating or certification appears because the model has learned the visual language of ads.

So I use this rule:

Product facts are fixed. The scene is editable.

The prompt order

For ecommerce images, I usually write prompts in this order:

Source product photo
Publishing channel
Editable scene or background
Must-keep product facts
Quality gate before publishing

That order matters.

If the prompt starts with "cinematic", "premium", or "high-converting", the model may optimize for the mood and treat product details as flexible.

If the prompt starts with the approved source product and the details that must not change, the output is easier to review.

A reusable product image prompt

Use the uploaded product photo as the fixed source of truth. Create an ecommerce product image for [channel: Shopify listing / marketplace / landing page / ad] with [background or scene direction]. Preserve product shape, proportions, label text, logo placement, color, material, texture, edges, contact shadow, and visible claims. Change only the background, lighting, surface, crop, and composition. Do not invent badges, ratings, certifications, discounts, accessories, or product features.

The important phrases are:

fixed source of truth
preserve product shape, label text, logo, color, material, and claims
change only background, lighting, surface, crop, and composition
do not invent badges, ratings, certifications, discounts, accessories, or features

Background prompt

Replace only the background of the uploaded product photo. Keep the product pixels, silhouette, label text, logo placement, color, material, texture, edges, proportions, and contact points unchanged. Create a clean ecommerce background with realistic surface contact, soft shadow, simple depth, and enough negative space for [listing / store hero / ad layout]. Do not alter the product, add text, add unsupported props, or create fake product claims.

This is useful when the product itself is already correct and the only job is to improve the scene.

Product repair prompt

Repair only the broken product details in the uploaded image: [warped label / distorted logo / broken edge / wrong shadow / color drift / damaged texture]. Preserve every accurate feature from the source product photo, including shape, proportions, label text, logo placement, color, material, and visible claims. Do not redesign the packaging, rewrite text, change the product color, add accessories, or alter the background beyond the repair area.

This is useful when an output is close, but one area failed.

Do not regenerate the whole image if only one label edge or shadow needs repair.

Review prompt

Review this AI-generated product image against the approved source product photo. Check product identity, variant, pack size, shape, proportions, label text, logo placement, material, color, texture, transparency, scale, included accessories, visible claims, badges, prices, and contact shadows. List every difference that could mislead a buyer. Mark each issue as pass, needs repair, or reject before the image is published.

This is the prompt I use after generation.

It changes the job from "make another pretty image" to "decide if this image is safe to publish."

My quick review gate

Before publishing, I check:

same product identity and variant
same silhouette and proportions
faithful label text and logo placement
truthful color, material, finish, and texture
believable scale against props or hands
no fake claims, badges, certifications, discounts, reviews, or endorsements
no marketplace or ad-policy risk

If the buyer would receive something different from what the image implies, I reject or repair the output.

Why I do not start with tool choice

The "best" AI product image tool depends on the job.

A background replacement task, a product repair task, an ad variant task, and a listing review task do not need the same workflow.

So I choose the workflow first, then the tool.

I turned this into a copyable ecommerce prompt pack here:

https://visualskillkit.com/ai-image-prompt-examples

And the scorecard I use before publishing is here:

https://visualskillkit.com/product-truth-scorecard

How I write product-safe AI image prompts for ecommerce

Fox leo — Tue, 07 Jul 2026 01:19:04 +0000

AI image prompts for ecommerce should not start with style.

They should start with product truth.

The failure mode I worry about is not an ugly image. It is a polished image that quietly changes what the buyer thinks they will receive.

So I use this rule:

Product facts are fixed. The scene is editable.

The prompt order

For ecommerce images, I usually write prompts in this order:

Source product photo
Publishing channel
Editable scene or background
Must-keep product facts
Quality gate before publishing

That order matters.

If the prompt starts with "cinematic", "premium", or "high-converting", the model may optimize for the mood and treat product details as flexible.

If the prompt starts with the approved source product and the details that must not change, the output is easier to review.

A reusable product image prompt

Use the uploaded product photo as the fixed source of truth. Create an ecommerce product image for [channel: Shopify listing / marketplace / landing page / ad] with [background or scene direction]. Preserve product shape, proportions, label text, logo placement, color, material, texture, edges, contact shadow, and visible claims. Change only the background, lighting, surface, crop, and composition. Do not invent badges, ratings, certifications, discounts, accessories, or product features.

The important phrases are:

fixed source of truth
preserve product shape, label text, logo, color, material, and claims
change only background, lighting, surface, crop, and composition
do not invent badges, ratings, certifications, discounts, accessories, or features

Background prompt

Replace only the background of the uploaded product photo. Keep the product pixels, silhouette, label text, logo placement, color, material, texture, edges, proportions, and contact points unchanged. Create a clean ecommerce background with realistic surface contact, soft shadow, simple depth, and enough negative space for [listing / store hero / ad layout]. Do not alter the product, add text, add unsupported props, or create fake product claims.

This is useful when the product itself is already correct and the only job is to improve the scene.

Product repair prompt

Repair only the broken product details in the uploaded image: [warped label / distorted logo / broken edge / wrong shadow / color drift / damaged texture]. Preserve every accurate feature from the source product photo, including shape, proportions, label text, logo placement, color, material, and visible claims. Do not redesign the packaging, rewrite text, change the product color, add accessories, or alter the background beyond the repair area.

This is useful when an output is close, but one area failed.

Do not regenerate the whole image if only one label edge or shadow needs repair.

Review prompt

Review this AI-generated product image against the approved source product photo. Check product identity, variant, pack size, shape, proportions, label text, logo placement, material, color, texture, transparency, scale, included accessories, visible claims, badges, prices, and contact shadows. List every difference that could mislead a buyer. Mark each issue as pass, needs repair, or reject before the image is published.

This is the prompt I use after generation.

It changes the job from "make another pretty image" to "decide if this image is safe to publish."

My quick review gate

Before publishing, I check:

same product identity and variant
same silhouette and proportions
faithful label text and logo placement
truthful color, material, finish, and texture
believable scale against props or hands
no fake claims, badges, certifications, discounts, reviews, or endorsements
no marketplace or ad-policy risk

If the buyer would receive something different from what the image implies, I reject or repair the output.

Why I do not start with tool choice

The "best" AI product image tool depends on the job.

A background replacement task, a product repair task, an ad variant task, and a listing review task do not need the same workflow.

So I choose the workflow first, then the tool.

I turned this into a copyable ecommerce prompt pack here:

AI image prompt examples for ecommerce

And the scorecard I use before publishing is here:

Product Truth Scorecard for AI product images

Building a transparent Roblox value calculator workflow without pretending live prices

Fox leo — Mon, 06 Jul 2026 06:40:19 +0000

I have been building LootKit, a small unofficial Roblox utility site for value references, W/F/L checks, mutation calculator workflows, and theme tools.

The most interesting technical problem was not the UI. It was deciding what not to promise.

For fast-moving game economies, a value page can become misleading very quickly if it pretends to be exact. A calculator can also create false confidence if it hides where the numbers came from, when they were updated, or how much uncertainty is involved.

So the first version of LootKit uses a different pattern:

value references instead of live prices
confidence labels instead of fake precision
update notes instead of silent edits
calculator handoffs instead of one magic number
clear unofficial disclaimers

This post breaks down the workflow.

The problem with game value tools

Players usually arrive with a practical question:

Is this trade W/F/L?
What is this pet or item worth?
Does a mutation change the estimate?
Why do two value lists disagree?
Can I use a calculator for this, or do I need a rough reference?

The tempting product answer is: show one number.

The better product answer is: show a decision path.

That matters because a game item is rarely defined by one field. For a Roblox value tool, the useful estimate often depends on a mix of:

base value
rarity
availability
mutation or trait modifiers
current demand
source confidence
last checked date
whether the user wants a reference value or a W/F/L decision

If a page collapses all of that into one “exact” number, it looks clean but becomes fragile.

The data model

I prefer treating each value row as a small evidence object rather than a price.

type Confidence = "low" | "medium" | "high";

type ValueReference = {
  game: "grow-a-garden" | "steal-a-brainrot";
  itemName: string;
  category: "pet" | "mutation" | "brainrot" | "trait" | "item";
  baseValueLabel?: string;
  rarity?: string;
  availability?: "common" | "limited" | "event" | "unknown";
  modifiers?: Array<{
    name: string;
    effect: string;
    confidence: Confidence;
  }>;
  confidence: Confidence;
  lastChecked: string;
  notes: string[];
};

The key field is not baseValueLabel. It is confidence.

The UI should make it obvious when a row is a stable reference, a rough estimate, or a placeholder that needs more evidence.

Why confidence labels belong in the interface

Confidence labels prevent two bad outcomes:

Users treat stale data as final.
Search engines see a page that looks complete but offers no evidence boundary.

On LootKit, the goal is to separate:

what the page can answer now
what it cannot answer yet
what depends on user context

For example, a Grow a Garden calculator page can handle a structured workflow:

base value
-> mutation multiplier
-> quantity
-> pet or item context
-> rough W/F/L read
-> confidence note

That is more useful than saying “this is worth X” without explaining the path.

The calculator should not replace the reference page

A value list and a calculator solve different problems.

A value list helps users identify the object and its current reference context.

A calculator helps users apply modifiers and compare trade scenarios.

For that reason, I usually design the page flow like this:

query intent
-> shortcut answer
-> reference table
-> worked example
-> calculator handoff
-> FAQ for edge cases

The worked example is important because it shows the rules in action.

For Grow a Garden calculator, that means showing how a user should think through a mutation or pet context before calling something W/F/L.

For Steal a Brainrot values, that means separating cost, income, rarity, mutation or trait, availability, and demand instead of pretending a single list can answer every trade.

Update notes are part of the product

If the underlying game changes often, the update log is not decoration. It is part of the user experience.

A simple update object can be enough:

type PageUpdate = {
  page: string;
  date: string;
  summary: string;
  changedSections: string[];
  reason: "new-query" | "community-question" | "data-refresh" | "content-fix";
};

This makes the page easier to maintain and easier to trust.

It also helps avoid a common SEO mistake: changing pages silently and losing the thread of why the page exists.

SEO benefit: answer the uncertainty directly

A lot of small SEO pages try to rank by repeating the query.

For utility pages, I think the stronger move is to answer the uncertainty behind the query.

Someone searching “value calculator” is not only asking for a tool. They are asking:

what inputs matter?
can I trust this number?
when should I use a list instead?
what does the calculator ignore?
how do I avoid a bad trade decision?

That is why the page needs:

a direct answer block
a visible calculation workflow
examples
confidence notes
FAQ sections
internal links to related value pages

This structure is useful for readers, search engines, and AI answer systems.

The rule I now use

If a value page cannot prove live accuracy, it should not look like a live market.

It should look like a transparent decision aid.

That is the design principle behind the current LootKit pages:

unofficial
practical
clear about uncertainty
structured enough to update
helpful before it is perfect

That last point matters. A small tool does not need perfect data on day one. It needs honest boundaries and a workflow users can actually apply.

You can see the early version here: LootKit.

A quick pre-upload checklist for YouTube thumbnails

Fox leo — Mon, 06 Jul 2026 03:24:44 +0000

I kept seeing the same small YouTube thumbnail mistakes show up before upload:

the file is the wrong shape,
the image is smaller than expected,
the file size is too large,
the format is not what the upload flow expects,
or the text is only readable inside the design tool, not in a small preview.

The fix is not complicated. Before uploading, check the file itself.

The checklist

Check	What to verify
Pixel dimensions	Use a 16:9 canvas. For serious uploads, avoid going below 1280 x 720.
Aspect ratio	Confirm the image is close to 16:9 before upload.
File size	Check megabytes separately from pixel dimensions.
Format	JPG and PNG are usually the practical defaults.
Small preview	Zoom out and make sure the main text still reads quickly.

A fast workflow

Export the thumbnail from your design tool.
Check width and height.
Confirm the aspect ratio is 16:9.
Check file format and file size.
Preview it small enough to mimic a mobile feed.
Fix the export settings and check the final file again.

The easy mistake is to treat dimensions and file size as the same thing. They are different checks. A thumbnail can be the right 16:9 shape but still be too large to upload. It can also be a small file but too low-resolution to look good.

Why I prefer local checking

For draft thumbnails, I usually only need the browser to read basic file metadata: width, height, file type, and file size. The image does not need to leave the device just to answer those questions.

I wrote the full checklist here:

https://imagesizekit.com/check-youtube-thumbnail-size-before-uploading/

It also links to a local checker for inspecting thumbnail dimensions, ratio, format, and file size before upload.

One caveat about Shorts

Do not mix standard YouTube thumbnails and Shorts covers. A normal video thumbnail is usually planned as a 16:9 image. Shorts are vertical and can behave differently across surfaces, so they need a separate export check.

A Product-Truth Check for AI Product Photography

Fox leo — Mon, 06 Jul 2026 03:04:46 +0000

AI product photography is useful, but the risky part is easy to miss.

The output may look polished while quietly changing the product.

A label gets rewritten. A logo shifts. A material becomes glossier. A product looks larger than it really is. A fake badge or rating appears because the model has learned what product ads often look like.

That is why I prefer to review AI product images with a simple rule:

Product facts are fixed. The scene is editable.

The safe split

Fixed product facts:

product identity
variant, pack size, and included accessories
shape, geometry, and proportions
label text and logo placement
material, color, texture, transparency, and finish
visible claims, badges, certifications, prices, and offer details

Editable layer:

background
surface
lighting
crop
composition
negative space
campaign mood
channel layout

The background can change. The product the buyer receives cannot.

A quick product-truth scorecard

Before publishing an AI-generated product image, compare the output against the approved source image at full size.

Score each item:

2 = pass
1 = needs repair
0 = reject

Test	Question
Identity	Would the buyer recognize the exact same product and variant?
Shape	Are proportions, silhouette, edges, and visible parts unchanged?
Label	Are label words, typography, and placement still faithful?
Logo	Is logo geometry, color, and placement unchanged?
Material	Does the finish still match the real product?
Color	Are color, variant, transparency, and texture truthful?
Scale	Does the product scale make sense against props or hands?
Shadow	Do contact shadows and reflections support the product instead of deforming it?
Claims	Were no fake claims, badges, reviews, discounts, or certifications added?
Channel	Would the image pass store, marketplace, ad, or landing-page review?

Decision rule

Total	Decision
18-20	Publish after final channel review
14-17	Repair the failed details before publishing
0-13	Reject or regenerate with narrower edit scope

I also use a few automatic reject rules:

product variant changed
label or logo was rewritten
fake certification, rating, price, claim, endorsement, or marketplace badge was added
product size, included accessories, or material was misrepresented
the image implies a buyer will receive something different

Prompt starter

Here is the kind of prompt I start from:

Use the uploaded product photo as the fixed source of truth. Create an ecommerce product image for [channel] with [background or scene direction]. Preserve product shape, proportions, label text, logo placement, color, material, texture, edges, contact shadow, and visible claims. Change only the background, lighting, surface, crop, and composition. Do not invent badges, ratings, certifications, discounts, accessories, or product features.

The important part is not the wording. It is the order:

start from the source product
name the publishing channel
define the editable scene
protect product facts before style words
inspect the output before publishing

Why this matters

AI product photography can reduce iteration time for ecommerce teams.

But the cost saving disappears if the image creates returns, rejected marketplace listings, customer complaints, or inaccurate advertising.

So I do not treat this as a model benchmark. I treat it as a workflow review protocol.

If the buyer would receive something different from what the image implies, reject or repair the output.

I turned the checklist into a simple Markdown scorecard here:

https://visualskillkit.com/resources/ai-product-photography-product-truth-scorecard.md

And the longer workflow page is here:

https://visualskillkit.com/ai-product-photography