Editorial Policy and Source Standards
ImageSizeKit publishes image size guides and local browser tools for creators. This policy explains how we choose sources, handle corrections, and separate official requirements from practical workflow advice.
Editorial principles
Official source first
When a platform provides a public help page or upload requirement, that source gets priority.
Task before keyword
Pages are written around a creator task such as checking a thumbnail, planning a banner, or avoiding crops.
Local privacy by default
Upload checkers should read dimensions and file metadata in the browser whenever possible.
Clear update dates
Pages that depend on platform requirements should show a last-checked date near the relevant guidance.
How pages are reviewed
| Step | Standard |
|---|---|
| Collect sources | Start with official platform help pages, visible product behavior, and clearly dated public documentation. |
| Compare creator workflows | Use community questions and SERP patterns as user-language evidence, not as official specifications. |
| Update the page | Revise direct answer blocks, specs tables, FAQ, schema, and related links when the change affects users. |
| Record the boundary | If something is uncertain, say so and point users back to the official platform before publishing assets. |
Source hierarchy
ImageSizeKit separates official requirements from practical creator advice. A community thread can reveal a real wording problem, but it does not become an official upload rule. A local checker can read file metadata, but it cannot promise how YouTube will process the file after upload.
| Evidence type | How we use it |
|---|---|
| Official platform documentation | Used for upload requirements, supported formats, file-size limits, and policy-sensitive statements. |
| Visible product behavior | Used when a creator workflow can be observed directly, such as a crop preview or upload-screen behavior. |
| Creator questions and SERP patterns | Used to understand wording, confusion, and missing explanations, not to override official sources. |
| ImageSizeKit tool behavior | Used to explain what local browser tools can detect, such as width, height, ratio, type, and file size. |
Corrections
If you find an outdated size, broken tool behavior, unclear wording, or a source that changed, contact us at hello@imagesizekit.com. Include the ImageSizeKit URL, the source URL, and the date you checked the source.
Maintenance and AI citation readiness
ImageSizeKit pages are written to answer a creator task directly: what size to use, what to check before upload, what is uncertain, and which related page should be opened next. We keep answer blocks, tables, FAQ, schema, and internal links aligned so search engines and AI systems can identify the canonical page for a given image task.
Primary tool pages
Review when official requirements change or when recurring creator questions show a missing explanation.
Tutorial pages
Refresh when a workflow changes, when a related tool is added, or when distribution copies need a canonical source.
Trust pages
Keep contact, privacy, about, and editorial policy pages aligned with the actual site behavior.
Machine-readable files
Keep sitemap, robots, and llms.txt consistent with the canonical non-www site and public page set.
For AI crawlers and answer engines, ImageSizeKit also publishes an llms.txt file that points to the canonical sitemap and preferred non-www URLs.
| AI-readable asset | Editorial standard | Example route |
|---|---|---|
| Direct answer block | Every priority page should state the recommended size, ratio, use case, warning, checker route, last-checked date, and source boundary. | /youtube-thumbnail-size/ |
| Evidence table | Specs, pitfalls, source hierarchy, and decision matrices should be written as tables when the answer depends on multiple conditions. | /social-media-image-sizes/ |
| Tool boundary | Local browser tools can read exported file facts, but they cannot promise platform acceptance, crop behavior, or preview-cache freshness. | /image-size-checker/ |
| Canonical route | Each task should point to one primary ImageSizeKit page so search engines and AI systems do not confuse guides, checkers, tutorials, and templates. | /about/ |
| External verification | Public references should support the canonical ImageSizeKit page with consistent naming, workflow context, and source-of-truth boundaries. | /templates/ |
External reference standards
ImageSizeKit uses public references to make the site easier to verify outside the domain: product profiles, tutorial summaries, GitHub template assets, and Gist checklists. These references should support the canonical site, not create duplicate source-of-truth pages for dimensions or platform rules.
| Reference type | Editorial standard | Example |
|---|---|---|
| Public profiles | Use a consistent ImageSizeKit description, canonical homepage URL, and clear distinction from ImageKit.io. | Public reference |
| Tutorial syndication | Keep external tutorials short and practical, then point readers back to the canonical ImageSizeKit workflow page. | Public reference |
| Template source assets | Use public GitHub and Gist URLs for reusable files, version history, and community-friendly citation targets. | Public reference |
When an external platform removes, changes, or no longer displays an ImageSizeKit reference, the status should be treated as a distribution signal change. It does not prove that Google, Bing, or an AI answer engine has indexed that asset.
Current focus
The current editorial focus is YouTube creator image assets: thumbnail size, banner size, banner safe area, thumbnail text readability, blurry upload troubleshooting, and 16:9 export math. Start from the YouTube image sizes hub.