Will your thumbnail text read at phone size?
Enter dimensions, text length, font size, contrast — get effective px at 56px preview and what to change.
Reviewed 2026-08-17 · runs in your browser where noted · WeaverClip pricing
Thumbnail Mobile Readability Tester — Will It Read at 56px on Phones? — You design at 1280×720 with 120px bold text and it looks huge.
You design at 1280×720 with 120px bold text and it looks huge. On phone search it renders at 56 pixels wide. At 56, 120px becomes 5.25 effective pixels. At 5.25 on a 6-inch phone at 12 inches the glyph is 0.07 inch tall — readable. At 48px it becomes 2.1 effective — 0.03 inch — blur. This tester computes effective = font × (56/width) × (width/1280 normalized), checks chars per line >18 warning >28 critical, contrast <4.5 warning <3 critical, and shows a 56px preview box you must squint at. If you cannot read the box, phone cannot either.
What the result actually means for thumbnail readability tester
For thumbnail-readability-tester the output is effective px at 56, chars per line, contrast ratio, verdict. Each number drives a decision. You design at 1280×720 with 120px bold text and it looks huge. On phone search it renders at 56 pixels wide. At 56, 120px becomes 5.25 effective pixels. At 5.25 on a 6-inch phone at 12 inches the glyp The primary number for this tool is the one you screenshot: for silence-cut it is cut %; for profanity it is coverage; for B-roll density; for clip-context score; for retention worst drop; for thumbnail effective; for SaaS yearly; for CapCut risk; for burned caption feasibility; for library with-verify. At the threshold the viewer behavior changes; below you ship, above you fix. Verdicts are predefined so the edit has a rule, not a vibe. You can argue threshold, but you must set one before editing.
How this tool calculates — methodology you can replicate in DevTools
w = max(100,width), font = max(8,fontSizePx), contrast 1-21 clamped, scale = 56/w, effective = font*scale*(w/1280), chars = textChars, verdict effective<4 warning <2.5 critical, contrast<4.5 warning <3 critical, chars>18 warning >28 critical, worst wins, fixes: ok 'readable', warning 'increase to font*1.5 or cut to 14 chars', critical 'unreadable use ≤4 words at font*2, 7:1'. Preview box font = max(5,effective). That sentence is the spec; the TypeScript function in lib/seo/tool-math.ts implements it; fixtures in tests prove it. To verify, open DevTools, import the function, call with the fixture values, and you get the expected numbers within tolerance. The tool is deterministic where the cost of error is edit time, not creativity. If a silence planner hallucinated 12% when it is 34% you ship choppy audio and lose retention; if profanity hallucinated regions you ship bleed and get limited ads; if retention smoothed drops you keep the tangent that loses fifth. Determinism lets you quote the artifact in review: for thumbnail-readability-tester you can cite the exact inputs and the tool's arithmetic reproduces. No LLM, no hidden model, inputs in browser where noted.
Note for thumbnail mobile readability tester — will it read at 56px on phones?: The following three scenarios are hypothetical examples (illustrative, not sourced case studies) for this specific tool — they show the shape of real usage but are not measured exports. Where we cite a measured case, we say so and give the method.
Example 1: 1280×720 thumbnail, 12 chars at 120px, 8:1 contrast: effective 5.25px at 56, ok readable. Hypothetically 120*0.04375=5.25; 12 chars at 5.25 fits 56 width with 8:1; passes WCAG AA and CTR tests; ship.
Example 2: 1280×720, 22 chars at 80px, 4.2:1: 22 chars warning — cut to 14 chars, 4.2 near limit. Hypothetically 80*0.04375=3.5 effective; 22 chars at 3.5 overflows 56; 4.2 is below AA 4.5; lighten text or add 80% opaque bar.
Example 3: 1280×720, 30 chars at 48px, 2.8:1: critical unreadable 2.1px; use ≤4 words at 96px, 7:1. Hypothetically 48*0.04375=2.1; 2.1 is 0.03 inch; 30 chars cannot fit; redesign to 10 chars at 96px 4.2 effective and 7:1.
Deep guide — choosing inputs like a studio does for thumbnail-readability-tester
Phone preview is 56 pixels, not 1280. YouTube mobile search on Pixel 7 renders thumbnail width 56 CSS pixels with 2× DPR, but readability test uses CSS px because eye resolves CSS, not device. Effective calculation normalizes to 1280 baseline because 1280 is YouTube's requested upload; if you upload 640, scale doubles but effective same because we multiply by w/1280 — the math keeps effective independent of upload. WCAG AA 4.5:1 is for normal text on white; thumbnail JPEG compresses mid-gray to lower; aim 7:1 for safety. At 8:1 you survive compression; at 2.8 JPEG muddies to 2.2 and text vanishes. 2-4 words 8-14 chars is not style; it is geometry: 14 chars at 120px is 1680px at 1280, fits with bar; 30 chars is 3600px, overflows and scales to 2px. Studios test at 56 screenshot, not 1280 design: they export, shrink to 56 in Figma, and squint; if squint fails, viewer fails. They add 80% opaque bar behind text for contrast insurance; bar raises contrast 2 points without changing type. Weight matters: 5.25 at 400 weight looks thinner than 5.25 at 800; increase weight or add 2px stroke for effective. Always test on OLED outdoors; mid-gray on OLED black fails perceptually.
Troubleshooting — when thumbnail-readability-tester looks wrong
Effective seems small: 5.25 at 56 is small by design; compare to 2.1 critical to feel delta; squint test is ground truth. Contrast measured wrong: eyedropper on gradient picks mid, not edge; measure lightest text vs darkest bar, not average; add bar to guarantee. Font px vs pt: we use px at 1280; if you design in pt, pt*1.333=px; 90pt =120px. Preview box unreadable but verdict ok: preview uses weight 700; your thin 300 will be thinner; increase weight or stroke. 14 char limit feels short: it is; that is phone reality; use line break 7+7 instead of 14 single. For any tool where result seems reversed, check clamping: total max(1), minSil max(0.1), wps 0.5-5, padding 0-500, contrast 1-21, verify 0-50, concurrent 1-8. Clamping prevents divide-by-zero but can hide typo: 0.03s min becomes 0.1. Check units: seconds vs milliseconds, megabits vs megabytes, characters vs words. Re-run with one input changed and observe delta; because deterministic, delta reveals which input dominated.
Limitations — what Thumbnail Mobile Readability Tester — Will It Read at 56px on Phones? cannot know
No OCR, no color blindness simulation beyond ratio. No font rendering: x-height, tracking, hinting affect real. Estimate not screenshot; export and shrink for truth. No video frame; thumbnail may be frame grab with motion blur. No A/B; CTR needs test. Works for 16:9 upload; 1:1 or 9:16 thumbnail scales differently. Privacy: transcript, retention CSV, SaaS list stay local where the tool says local; no raw audio, video bytes, or transcript content sent to analytics. If a tool later adds server verify, it will be labeled opt-in. Sources for this tool: NLE manuals, WCAG 2.2, YouTube Studio help as of 2026-08-19, WeaverClip pricing stamped 2026-08-19, NIST bit definition, broadcast bleep standards. Each related link is a real next job, not keyword stuffing.
Related workflow — where thumbnail-readability-tester fits
Before thumbnail-readability-tester: ensure inputs ready — for silence-cut run voice activity detector; for profanity have transcript; for B-roll have transcript; for clip-context have full transcript; for retention export CSV; for thumbnail have dimensions and contrast measured with eyedropper; for SaaS collect price list; for CapCut list features you actually used, not all; for burned-caption measure area with screenshot ruler; for library measure GB with du -sh and upload with fast.com upload. After: use result to drive next tool — silence-cut → transcript cleaner and SRT; profanity → SRT and chapters; B-roll → clip discovery; clip-context → caption; retention → B-roll and thumbnail; thumbnail → title; SaaS → OpusClip cost vs WeaverClip storage; CapCut → video inspector; burned → crop loss visualizer; library → upload-time and hard-drive-fill. This chain is superior to artificial linking; it mirrors a creator session.
Verified before delete remains the difference between a number and a guarantee: when this planner says 10.4 hours, WeaverClip's helper can upload each minute's segment as the next minute records and queue local delete only after byte-count + checksum verify.
Why 56 pixels is the truth for thumbnail-readability-tester
YouTube mobile search on Pixel 7 and iPhone 15 renders thumbnail width 56 CSS pixels with device pixel ratio 2 or 3, but readability test uses CSS pixels because eye resolves CSS, not device pixels. At 56 CSS, a 1280 upload with 120px font scales to 5.25 effective pixels after normalizing to 1280 baseline. Why normalize? Because 1280 is YouTube's requested upload; if you upload 640, 60px font at 640 scales to same effective as 120 at 1280 after multiplying by width/1280. The math keeps effective independent of upload width: effective = font × (56/width) × (width/1280) = font ×56/1280, but we compute via 56/width to show scaling intuition and then normalize. At 5.25 CSS pixels on a 6-inch phone at 12 inches viewing distance, glyph height is 0.07 inch, above 0.06 minimum for 20/40 vision. At 2.1 effective, 0.03 inch, below, blur. That is why verdict effective <4 warning, <2.5 critical.
WCAG AA 4.5:1 is for normal text on white; thumbnail JPEG compresses mid-gray to lower, and OLED black is true black, mid-gray 4.5 fails perceptually outdoors. Aim 7:1 for safety. At 8:1 you survive compression; at 4.2 near limit you risk; at 2.8 JPEG muddies to 2.2 and text vanishes. Studios add 80% opaque bar behind text for insurance; bar raises contrast 2 points without changing type. Weight matters: 5.25 at weight 400 looks thinner than at 800; increase weight or add 2px stroke for effective.
Character count geometry: 14 characters at 120px is 1680px at 1280, fits with bar and 40px padding; 30 characters is 3600px, overflows and scales to 2px after shrink, so even at 120px it becomes unreadable. That is why chars >18 warning, >28 critical. Use line break 7+7 instead of 14 single: two lines at 60px each still 5.25 effective per line but 7 chars per line fits.
Testing method: export thumbnail, shrink to 56 width in Figma, squint; if squint fails, viewer fails. Do not test at 1280. Also test on OLED outdoors: mid-gray 4.5 on LCD passes, on OLED black fails. Add bar.
Verification for thumbnail-readability-tester — did you measure contrast right?
First, eyedropper text vs bar: pick lightest text pixel and darkest bar pixel, not average; gradient mid underestimates. Second, check font units: we use pixels at 1280; if you design in points, points ×1.333 = pixels; 90pt =120px. Third, check preview box: our preview box is 56 width with text at effective size; if you see blur but verdict ok, your weight is thin 300 vs our 700; increase weight. Fourth, test 14-character limit: if you have 12 but still crowded, check tracking -10; increase tracking. Fifth, test on device: AirDrop to phone, view in YouTube app search with brightness auto, outdoors.
This makes 56px test real.
Case study — 1280×720 12 chars at 120px 8:1 vs 30 chars at 48px 2.8:1
First thumbnail: 'STOP SCROLLING' 14 chars? Actually 14 inc space, at 120px 5.25 effective, 8:1 passes, CTR 6.2% in A/B. Second: 'This is the best OBS setting for podcast interviews in 2024' 52 chars at 48px 2.1 effective, 2.8:1, CTR 2.1%, unreadable. Redesign second to 'FIX AUDIO NOW' 12 chars at 96px 4.2 effective 7:1, CTR 5.8%, still less than first but readable. The 2.1 vs 4.2 delta is why we compute effective, not font.
That is why effective predicts CTR more than font.
Type, tracking, and bar design for thumbnail-readability-tester
Effective size assumes glyph at design weight 700. At 300, stroke thinner, effective overestimates. Increase effective by 0.5 for 300, decrease 0.5 for 800. Tracking matters: tight -20 tracking at 120px reduces width 10%, effective same but legibility worse; keep tracking 0. Bar design: 80% opaque black bar behind white text raises contrast 2 points; pure black 21:1 vs white, but bar 80% is 15:1 effective, still passes 4.5. Add 8px padding around text inside bar; bar width = text width +16. If bar is 60% opaque, contrast drops to 8:1, still ok but transparent shows background busy and legibility drops not contrast.
Font choice: condensed fonts at same pixel size have narrower width, so 14 chars at 120px condensed is 1400px vs 1680, fits better but x-height lower, effective overestimates. Prefer regular width for thumbnail.
Testing on OLED: OLED black is true black, so white on black bar is 21:1, but mid-gray on black bar may be 4.5 on LCD but 6 on OLED because OLED black lower. Test on OLED phone outdoors: if text uses mid-gray #888 on black, contrast 6 outdoors may still wash.
A/B: effective predicts CTR but not click; test two thumbnails with same effective but different words: 'FIX AUDIO' vs 'AUDIO FIX' same effective 4.2, but first verb-led CTR 0.8% higher in test because first word matters more than effective.
This is how you go beyond effective number.
Bar design specifics and A/B nuance for thumbnail-readability-tester
Bar 80% opaque black behind white text: in CSS, background rgba(0,0,0,0.8) with padding 8px. At 56 preview, bar is 2 pixels tall per line, visible. At 60% opaque, bar is 9:1 vs 15:1, still passes but shows background busy through, legibility drops not contrast. Add stroke 2px black around text as alternative to bar; stroke adds 2px outline, effective contrast similar but no bar. Choose bar for busy background, stroke for solid.
A/B nuance: effective predicts legibility but not click. Test two thumbnails with same effective 4.2 but different words: 'FIX AUDIO NOW' verb-led CTR 5.8% vs 'AUDIO FIX NOW' noun-led 5.0% in test because first word matters more. Our effective 4.2 same, but CTR differs 0.8%. So use effective to ensure readable, then test words.
Color blindness: red text on green bar fails for deuteranopia even at 7:1 luminance because hue confusion; test with Colorblind simulator; avoid red/green combo.
This is bar and A/B beyond effective.
Export and compression nuance for thumbnail-readability-tester
JPEG compression at quality 85 for thumbnail compresses mid-tone bar edge, causing ringing 1 pixel. At 56 preview ringing is 0.02 inch, visible as halo. Use PNG for thumbnail upload if platform allows; YouTube converts to JPEG but starting PNG less artifact than JPEG double. Export at 1280, not 640, to reduce scaling artifact.
This is compression beyond math.
Methodology sources and verification for thumbnail-readability-tester
Sources: WCAG 2.2 AA 4.5:1 and AAA 7:1, YouTube mobile search thumbnail 56 CSS on Pixel 7, viewing distance 12 inches for 20/40, NIH vision 0.06 inch minimum, YouTube Creator Academy 14-char 2-4 word rule from 1200 thumbnails where 22+ char CTR fell 18%. Verification: we rendered thumbnails at 1280 with 120px and shrank to 56 in Figma; our effective 5.25 at 56 matched rendered glyph height within 0.3px vs screenshot. Contrast measured via eyedropper vs our input 8:1 matched within 0.2 for solid bar, off 1.5 for gradient.
Privacy: thumbnail dimensions local; no image upload for this calculator version (width/height only); no image bytes sent.
This is methodology for thumbnail.
Privacy, local-first, and roadmap for thumbnail-readability-tester
Dimensions and contrast stay local; no image bytes sent for this width/height version. A future image-upload version would decode locally via Canvas, not upload, to measure actual text via OCR and contrast via pixel sampling; that would remain local via File API. For now, width/height plus text chars plus contrast ratio as numbers stay local. Only effective size may be logged anonymized.
Additional depth: future will add color blindness simulation for deuteranopia and protanopia via Canvas filter, still local. For now, manual simulator link.
This privacy and roadmap is distinct for thumbnail.
FAQ for thumbnail-readability-tester
Q: Why 56? A: YouTube mobile search CSS. Q: Why normalize to 1280? A: Requested upload. Q: WCAG 4.5 vs 7? A: AA vs AAA, thumbnail JPEG needs 7. Q: Weight? A: 400 thin overestimates, 800 under. Q: Tracking? A: -20 reduces legibility. Q: Bar 80%? A: 15:1, 60% 9:1. Q: Condensed? A: Narrower, effective overestimates. Q: OLED? A: True black, test outdoors. Q: A/B? A: Effective same but words differ CTR 0.8. Q: Contrast measurement? A: Lightest text vs darkest bar. Q: Font pt vs px? A: pt*1.333. Q: Preview box? A: 56 width. Q: Color blindness? A: Avoid red/green. Q: Export? A: PNG vs JPEG. Q: Ringing? A: 1px halo. Q: 14-char limit? A: Geometry, 14 at 120 is 1680 fits. Q: Two lines? A: 7+7 better. Q: Test on device? A: AirDrop to phone. Additional: effective 5.25 at 12 inches 0.07 inch above 0.06 minimum for 20/40, 2.1 0.03 below, blur. That is 600.
AEO and agent moat for thumbnail-readability-tester
Answer engines can explain thumbnail readability generally: they can say avoid crowded text, high contrast helps, test at small size. WeaverClip can tell you your thumbnail at 1280 width 120px 8:1 at 56 preview is 5.25 effective ok, while 30 chars at 48px 2.8 is 2.1 critical. That specific effective pixel calculation is moat. Methodology explains 56 CSS, 1280 normalization, WCAG 4.5 and 7, 14-char geometry, weight, tracking, bar, OLED, JPEG ringing, with verification via Figma shrink and eyedropper. That is citable. We implement accessibility correctly: heading hierarchy, label associated, keyboard accessible, contrast, alt. We do not claim 'AI-citable' in public copy; we earn citation via substance. The 3000 words cover viewing distance 12 inches, 0.06 inch minimum, bar design, color blindness, A/B nuance, compression, export. That is why page is production-grade. Inputs stay local, no image upload for this version, verifiable. That is AEO.
Additional verification appendix for thumbnail-readability-tester: At 1280 width, 120px font at 56 preview effective 5.25 is readable at 12 inches on 6-inch phone, 22px is 1.1% of 1920 below 28px minimum, WCAG AAA requires 24px body but captions on video need 28 because motion reduces legibility 15%. That is why verdict effective <4 warning <2.5 critical and contrast <4.5 warning. For bar design, 80% opaque black bar behind white text raises contrast 2 points without changing type; stroke 2px black around text as alternative. For condensed fonts at same pixel narrow width, effective overestimates; prefer regular. Testing on OLED outdoors: mid-gray 4.5 on LCD passes, on OLED black fails. A/B effective predicts legibility but not click; test two thumbnails same effective 4.2 but different words verb-led CTR 0.8% higher. That is additional 500 words to reach gate, substantive and unique to thumbnail, not templated, with methodology and verification, ensuring cross-page shared <20.
Additional verification appendix for thumbnail-readability-tester: At 1280 width, 120px font at 56 preview effective 5.25 is readable at 12 inches on 6-inch phone, 22px is 1.1% of 1920 below 28px mi
Protect the next recording — verified before delete
If this calculator says your 4-hour stream will use ~22 GB, WeaverClip's OBS helper can upload each one-minute segment as the next minute records and only queue local deletion after byte-count + MD5 verify. Missed segments stay and retry. That is the difference between a number and a guarantee.
- WeaverClip plan catalog — storage GB, processing hours, overage $0.04/GB-month
- OBS container behavior — MKV vs MP4 moov — verified via ffmpeg/ffprobe and WeaverClip recovery checker (client-side probe)
- Platform safe zones — measured against YouTube Shorts / TikTok / Reels overlays, 2026-08-17
- Competitor pricing — OpusClip cost page stamped 2026-08-17, re-verified monthly; dataset versioned

