OG图生成器把标题里的emoji切成了两个方块，断行这一步它只认字符不认词

摘要：在标题框里打一个火箭emoji，画布上大多数时候都好好的。但只要它正好落在换行的位置，就会裂成两个菱形问号，一个留在上一行末尾，一个跑到下一行开头。输入框里显示的还是完整的火箭。

根子在断行那一步：它一个码元一个码元地往下量宽度，量到超了就断。汉字碰巧一个字一个码元，所以中文看起来完全正常；英文单词会被从中间劈开，emoji这种占两个码元的字符则会被劈成两半。

这款工具的定位很清楚：给没有设计资源的人，五分钟做出一张能看的社交分享图。填标题、选版式、挑配色、下载，四步结束。它的页头副标题写着六个字：中文自动换行。

这六个字比它看起来要准确得多——准确到几乎是一句免责声明。中文确实自动换行，而且换得没毛病；其他情况就得看运气了。

为什么标题里的emoji会变成两个方块？

先说这个，因为它最反直觉：同一个emoji，放在标题的大多数位置都好好的，只有落在某个特定位置才会碎。

怎么把它逼出来

我写了个循环，用"独"字当填充，从1个开始一直加到30个，每次在后面接一个火箭emoji，再接一段固定的文字，看断行落在哪里。30个长度里命中了1个：前面刚好13个汉字的时候。

这时候画布上的三行是：

• 第一行：13个"独"字，然后一个菱形问号
• 第二行：又一个菱形问号，然后是"立站出海要点全解析补充说明"
• 第三行："文字"

而右边的输入框里，火箭还是完完整整一个火箭。

量一量那两个方块有多宽

光看着像方块不算数，我用画布自己的文字测量接口量了一遍，字体和字号都用工具真实使用的那一套（800字重、72像素）：

• 完整的火箭emoji：98.86像素
• 被劈开的前半截（孤立的高位代理）：69.93像素
• 被劈开的后半截（孤立的低位代理）：69.93像素
• 两半加起来：139.86像素
• Unicode替换字符（就是那个菱形问号本尊）：69.93像素

两半的宽度和替换字符一模一样。这就等于确认了：它们各自被字体渲染成了一个"我不认识这个字符"的方块。而且劈开之后总宽度比原来还多了41像素——工具的换行是为了不超宽才断的，结果这一断反而更宽了。

为什么会这样

断行代码是逐个字符往前走的：取一个字符，跟已经攒着的这行拼起来量宽度，超了就在这里断。问题在"取一个字符"这一步用的是方括号取下标。

MDN的说明写得很清楚：在UTF-16里，每个字符串下标对应一个码元，取值0到65535；更高的码点要用一对16位的代理伪字符来表示。emoji正好在这个"更高"的范围里，所以一个火箭在字符串里占两个下标。

循环一个下标一个下标地走，只要不断行，两个半截会被依次拼回同一行，看着完好无损。一旦断行点正好落在这两个下标中间，一半留在上一行，一半跑到下一行，谁也不成字。

为什么输入框里看着是好的

这一点值得多说一句，因为它决定了你能不能在下载之前发现问题。

右边的标题输入框是个普通的多行文本框，里面的文字由浏览器的排版引擎负责渲染。排版引擎认识字素簇这个概念——它知道那两个码元合起来是一个字符，绝不会从中间断开。

左边的画布则完全是另一回事。画布上没有排版引擎，每一行文字都是代码自己算好位置、自己画上去的。断在哪、怎么对齐、要不要避头尾，全部由那几十行代码说了算。

所以你会看到一个很别扭的局面：同一段文字，右边显示正常，左边裂开了。而人的注意力在填表的时候天然落在输入框上，图那边只是余光扫一眼"嗯有字了"。等发现不对，图已经传上去了。

这类问题为什么特别难被发现

它是概率性的。同一个emoji放在标题开头没事，放在中间没事，只有落在那个宽度临界点上才出事。而临界点取决于标题的字数、字号（工具会随字数自动缩字号）、画布宽度（三档尺寸各不相同）以及emoji前面那些字各自多宽。

换句话说：你测的那几个标题都好好的，然后某一篇文章的标题恰好踩中，图就这么发出去了。这跟站内那篇讲一个emoji到底该怎么数字数的文章说的是同一件事的两面：一个人眼里的"一个字"，在程序里可能是1、2、5甚至8个不同的数。

英文标题它是怎么断的？

emoji那条是概率事件，英文这条则是必然的。

三行里劈开两处

我把工具的断行算法原样复刻了一份，用页面上同一个画布上下文、同一个字体字符串跑，这样得到的结果和工具画出来的完全一致。素材是一个典型的英文长标题：

Understanding Internationalization and Localization Requirements

1200×630的默认尺寸下，它断成这样：

• Understanding Internationa
• lization and Localization Re
• quirements

Internationalization被切成了Internationa和lization，Requirements被切成了Re和quirements。三行里两处劈在单词中间。

中英混排也一样

纯英文标题在中文站上不算常见，但混排太常见了。试一个更贴近实际的：

🚀 独立站出海第一课：把og:image配对 🎯 点击率才有救

结果是og:i断在第一行末尾，mage去了第二行。一个所有人都认识的属性名，被从中间锯开了。

Unicode对这件事有明文规定

这不是审美问题，是有标准的。Unicode的换行算法附件（UAX #14）把字符分了类，其中说得很直白：普通的字母类字符"需要其他字符来提供断行机会，否则它们两两之间不允许断行"。也就是说，字母之间除非有空格、连字符这类东西，否则根本就不该断。

同一份文档对表意文字（也就是汉字）的说法则完全相反："带有这个属性的字符不需要其他字符提供断行机会，行可以在表意文字之前、之后以及两个表意文字之间正常断开。"

这两句话放在一起，就解释清楚了工具为什么"中文自动换行"这句话是准的：它的算法恰好就是表意文字那一套规则，而这套规则套到字母上是错的。作者写的时候大概只想着中文，页头那六个字也就成了一句诚实的免责声明。

字号一动，所有断行点跟着挪

还有一层机制让这件事更难预测。工具会自动缩字号：先按最大字号排一次，如果行数超了限制（横版最多三行，方图最多五行），就把字号减4再排一次，一直减到放得下为止，最低减到30像素。

字号变了，每个字占的宽度就变了，于是所有断行点整体重排。这意味着：

• 你在标题里多打一个字，可能触发一次降档，整张图的分行方式全变
• 你删掉一个字，可能反过来升回上一档，同样全变
• 本来好好的emoji，在新的分行下可能正好落到断点上

所以"我上次这么写没问题"这句话在这里不成立。它不是一个稳定的映射关系，是一个每次都要重算的动态结果。这也是我建议手动换行的另一个理由——手动断行的位置是你定的，不会被字号变化牵着走。

顺带说说测量接口

用来量宽度的那个接口，MDN的描述是它返回一个包含被测文本信息（比如宽度）的对象。它就是一把尺子，只负责量，不负责告诉你哪里能断。分词、断行机会、避头尾这些事，全得调用方自己做——工具没做，尺子也不会提醒它。

中文的逗号为什么会跑到行首？

说完了"中文没问题"，得补一句：中文也不是完全没问题。

构造一个逗号落在行首的标题

还是那个循环，这次填充字用"测"，后面接一个中文逗号，再接一段占位文字。14个"测"字的时候命中了：

• 第一行：测测测测测测测测测测测测测测
• 第二行：，后面还有一些内容用来占位补
• 第三行：足长度

第二行是以逗号开头的。

这条规矩叫行首禁则

W3C那份《中文排版需求》里有专门的一节讲行首行尾禁则，规定了哪些标点不能出现在行首、哪些不能出现在行尾。逗号、句号、顿号、问号、叹号、右括号、右引号这一类，全都不能在行首；左括号、左引号这类则不能在行尾。

浏览器渲染普通网页文字时会自动处理这件事，所以做网页的人很少需要操心。但画布上的文字是自己一行行画的，浏览器的排版引擎完全没参与，这些规则就得自己实现。

发生概率有多高

比emoji那条高得多。中文标题里带逗号、冒号、破折号的比例本来就大，而中文每个字宽度一样，断行点相当于在标题里均匀滑动。粗略估算，一个含标点的中文标题撞上行首禁则的概率在十分之一这个量级。

好在后果比emoji轻——逗号跑到行首只是不好看，不影响读。但它出现在一张要被几千人在信息流里刷到的图上，多少有点掉价。中文排版规范化工具那篇里讲过一个类似的现象：中文排版的规则大多藏在"看着别扭"这个层面，不到有人指出来很难说清哪里不对。

能怎么绕

标题框支持手动换行。既然自动断行处理不了这些，那就干脆自己断：在你想换行的地方按回车，工具会照着你的换行来分行。这是目前唯一可靠的办法，也顺便解决了英文劈开和emoji碎裂——只要你自己断的位置是对的。

方图那一档，发到信息流里会少掉什么？

换个话题，从文字转到版式。

先量出四个元素各自在哪

把尺寸切到1080×1080，填上标题、副标题、左下角署名和右上角标签，然后逐行扫描画布，找出哪些行有内容：

• 右上角的标签：纵向76到116像素
• 主标题：465到527
• 副标题：571到592
• 左下角的署名：987到1008

再算一下1.91比1的裁切保留哪一段

那些以横版大图卡片展示链接的平台，用的比例是1.91比1。一张1080宽的方图要塞进这个比例，保留的高度是1080除以1.91，约等于565像素。居中裁切的话，上下各切掉257像素，可见区间是纵向258到822。

把两组数字对一下：

• 标签在76到116 —— 整个在可见区上方，没了
• 主标题465到527 —— 在区间内，活着
• 副标题571到592 —— 在区间内，活着
• 署名987到1008 —— 整个在可见区下方，没了

标题和副标题一个字不少，右上角的品类标签和左下角的品牌署名双双消失。而署名那一行往往是你唯一的品牌露出。

1600×900那一档呢？完全没事

为了确认问题只出在方图，我把同样的测量在1600×900上又做了一遍：

• 右上角标签：112到172
• 主标题：338到431，副标题：495到529
• 左下角署名：753到794
• 1.91比1的可见区间：31到869，单边只裁掉3.4%

四个元素全在可见区里，一个都没丢。原因很简单：16比9约等于1.778，跟1.91本来就差得不多，裁掉的那点边缘刚好落在7.5%的内边距里——这才是"预留了安全边距"这句话真正生效的场景。

所以三档尺寸的结论是分开的：1200×630是原生比例，零裁切；1600×900小裁一点，四个元素都保得住；只有1080×1080会掉角。

"已经预留了安全边距"这句话的问题

工具的说明里写着：各平台裁切规则不一样，边缘留出至少5%的安全区，标题才不会被切掉，这款工具的版式已经预留了安全边距。

它确实留了，而且留得比说的还多——实际内边距是画布宽度的7.5%。问题是这两件事根本不是一回事：

5%的边距防的是"贴边被切掉一点点"，比如圆角遮罩、平台加的小幅裁边。而方图进1.91比1的框，要切掉的是上下各23.8%。这不是边距能挡的量级，是构图问题——关键元素必须落在中央那条横带里，跟你留多少边距没有关系。

那这一档还能用吗

能，前提是别混用。工具在说明里给1080×1080的定位是对的：以方图为主的平台，以及朋友圈这类展示位。在那些地方它是原生比例，什么都不会掉。

真正的风险是同一张图到处发。做内容的人的常见习惯是一篇文章配一张图，各个渠道都用它。如果这张图是方的，那么在横版大图卡片的平台上，你的品牌名就消失了，而你在自己电脑上看到的预览一切正常。

稳妥的做法是方图那一档只用来出方图，横版另出一张；或者退一步，做方图时把署名和标签当成装饰，别把非有不可的信息放进去。想在发之前看看各平台实际会裁成什么样，站内那款Open Graph预览器就是干这个的，两款工具正好接得上。

为什么它只给PNG，而这恰好是最不该给的格式？

下载按钮上写的是"下载PNG"，界面上没有格式选项。翻代码也确认了：导出格式是写死的，连质量参数都没传。

三档尺寸的实际体积

同一张图（标题加副标题加署名加标签，深色配色），三档尺寸各导一次，再拿同样的画布内容分别编成JPEG和WebP做对照：

1200×630那一行：PNG是WebP的18.4倍，是JPEG的9.1倍。一张392 KB的图，本来可以是21 KB。

为什么这张图的PNG这么大

PNG是无损格式，它擅长的是颜色少、有大片规律的图。而这张图正好相反，我数了一下画布上的颜色种类：1541种。

来源有两处。一处是背景右下角那团柔和的光晕，那是个径向渐变，天生就是成百上千种颜色。另一处是文字的抗锯齿边缘，每个字的轮廓都是一圈从背景色过渡到文字色的灰阶。

我做了个验证：把画布上跟背景色差异很小的像素统统吸附成纯背景色，等于人工抹掉那团渐变，再导一次PNG——从401 KB降到181 KB。渐变一个人贡献了55%的体积，剩下的基本是文字抗锯齿。

1600×900那一档为什么更贵

表格里1600×900是659 KB，比1200×630的401 KB多了64%。这个涨幅比像素数的涨幅小——1600×900的像素数是1200×630的1.9倍，体积只涨到1.64倍。

原因是文字并没有跟着画布等比变大到那个程度：字号按宽度比例放大，但文字占的面积比例不变，而背景那片渐变虽然面积大了，渐变本身很平滑，PNG的行间预测对它相对友好一些。

不过这不改变结论：三档尺寸的PNG全在400 KB到660 KB这个区间，没有一个是可以直接上传的体量。选1600×900当文章封面图的人尤其要注意，那是要进首屏的资源。

这件事的实际后果

OG图是抓取程序去拉的，不是用户主动点开的。392 KB对现代带宽来说不算大，但它乘上你的文章数量就成了一笔账；更直接的是，同一张图你多半也会拿去当文章封面图，那时候它就是实打实的首屏资源了。

解法很简单：导出之后过一遍压缩。图片压缩与格式转换那款工具正好接在这一步——不过要注意，这张图有渐变、有大量抗锯齿灰阶，属于照片那一类，画质给0.8到0.85就好，别拉满。

格式上则要留意平台的接受度：主流平台对JPEG和PNG都没问题，WebP的支持度这几年才补齐，如果你的读者分布很杂，JPEG是最不会出事的那个。

那两个字数上限，其实是这个版式唯一的保险丝

这一节是给这款工具说句公道话的。

我原本以为这里会出事

看代码的时候我注意到：副标题换行之后，行数是不限制的，也不截断，有几行画几行。而主标题下面紧接着就是副标题，副标题下面是固定位置的署名。照这个写法，副标题一长就该把署名压住。

于是我把两个输入框都填满上限——主标题60个字，副标题80个字，一个字符都不剩——然后扫描画布：

• 主标题占三行：143到189、207到253、271到317
• 副标题占三行：354到379、396到421、439到463
• 署名：527到551

内容最后一行的底边是463，署名的顶边是527，中间空着64像素。不重叠，而且余量还挺舒服。

保险丝装在别处

我又把副标题的字数上限临时改大，继续往里灌字。到240个字的时候，署名那一条横带才开始被碰到。

也就是说：绘制逻辑里确实没有防线，防线装在两个输入框的字数上限里。主标题60、副标题80这两个数字，看起来只是提醒你"别写太多"，实际上是在替版式兜底。

这条给的启发

读代码读出一个"这里肯定要出事"的判断，然后实测发现没事，是很常见的事。原因往往就是这种：约束不在你正在读的那段代码里，而在上游某个不起眼的属性上。

反过来说，这个设计也有点脆——那两个数字如果哪天因为"用户反馈标题不够写"被调大，压住署名的问题会立刻出现，而改动的人未必知道自己动的是一根保险丝。

八组配色里，有没有哪一组看不清？

再说一条正面的。这类生成图工具最容易翻车的地方是配色——设计师挑的配色好看，但对比度不够，缩略图一小就糊成一片。

把八组配色的对比度全算一遍

每组配色有四个颜色：背景、主文字、强调色、次要文字。按WCAG的公式算出这几组搭配的对比度：

• 主标题（主文字压背景）：13.04到18.88，八组全部远超标准
• 副标题和署名（次要文字压背景）：最低5.35，最高7.92
• 右上角标签（背景色文字压强调色底）：最低4.02，最高7.49

4.02这个数字要不要紧

WCAG对普通文字的要求是至少4.5比1，大号文字放宽到3比1。4.02夹在中间，所以得看那个标签算不算大号文字。

标准里对大号文字的定义是"至少18磅，或者14磅加粗"，文档还给了换算："14磅和18磅大致相当于18.5像素和24像素"。工具的标签用的是22像素、700字重，属于加粗，超过18.5像素这条线，适用3比1的标准。4.02高于3，达标。

八组配色，四个位置，没有一组踩线。这在我测过的这类工具里算难得——毕竟配色是最容易凭感觉挑的东西，而凭感觉挑八组还组组达标，说明是认真算过的。

图做完之后，标签该怎么写才不白做？

图只是一半，另一半在页面的标签里。这里有个被普遍误解的地方值得说清楚。

1200×630不是标准，是习惯

Open Graph协议的规范里，og:image是四个必需属性之一，定义是"一个能在图谱中代表你这个对象的图片地址"。协议还定义了几个可选的子属性：og:image:url、og:image:secure_url、og:image:type、og:image:width、og:image:height、og:image:alt。

然后就没有了。规范里没有任何一句话规定尺寸、比例或者体积上限。1200×630这个数字来自平台的裁切习惯，不是协议要求。这个区别在实际工作里有用：当某个平台的展示效果和你预期不一样时，去查那个平台的文档，别去翻协议。

那个最常被漏掉的属性

协议列的六个子属性里，og:image:alt是最常被忘掉的一个，它的定义是"对图中内容的描述（不是图注）"。

工具的说明里给了一段可以直接抄的标签示例，包含og:image、宽、高和卡片类型，唯独没有alt。补上它成本是零，对读屏软件的用户和某些平台的无障碍展示都有意义。既然图上的字对搜索引擎是不可读的（这一点工具的FAQ说得很对：搜索引擎不会去认图里的字，它读的是og:title和og:description），那么alt就是这张图唯一能被机器读到的文字。

图上的字和标签里的字，各管各的

这里有个容易混淆的地方：图上那行大标题，和og:title标签里的文字，是两份互不相干的内容。

分享卡片展示的时候，图归图、标题文字归标题文字，两者上下排布。抓取程序读的是标签，人看到的是两者叠加的效果。所以这两份文字不必一样，甚至不该完全一样——重复两遍同一句话，等于浪费了卡片上一半的展示面积。

一个更好的分工是：标签里放完整准确的句子，图上放最短的那个钩子。标签那句要对搜索和抓取负责，得把话说全；图上那句只对"要不要点"负责，越短越有力。工具建议主标题20个汉字以内，从这个角度看也是合理的。

顺带说，图上的字还有一个标签替代不了的作用：在那些不展示描述、只展示大图和一行小标题的展示位上，图上的字是唯一能承载多一句话的地方。

其余三件事

工具说明里提到的三条都是对的，值得重复：地址必须写绝对路径；图不能放在需要登录才能访问的位置；宽高标签建议一起写，能让平台在图片下载完成前就预留出正确的位置。

再补一条它没提的：改了图之后各平台的缓存不会自动更新，而且很多平台没有提供强制刷新的入口，最保险的做法是换文件名。这跟站内那篇讲OG社交分享图尺寸与动态生成的文章里说的一致：OG图应该在文章发布之前就配好，发布之后再补，代价比你想的大。

哪些字该进这张图，哪些不该？

最后收一份能直接照做的清单。

标题：越短越安全，而且不只是为了好看

工具建议主标题20个汉字以内。这个建议除了"信息流里显示尺寸小"这个理由之外，还有一个从前面推出来的理由：标题越短，行数越少，撞上断行问题的机会就越少。一行的标题永远不会有断行问题，两行的概率减半。

emoji：要么别放，要么放行首

如果一定要放，放在标题最开头。开头位置永远不会是断行点，因为断行只发生在当前行放不下的时候，而第一个字符总是放得下。放在标题中间和末尾都有风险。

英文和网址：手动断行

标题里含英文单词、属性名、域名的，直接在输入框里手动按回车分行，别让它自己断。判断哪里该断很简单：在空格处断、在标点处断，别在字母中间断。

方图：署名当装饰

做1080×1080的时候，默认右上角标签和左下角署名会在横版平台上消失。如果这张图只发方图平台，随便放；如果可能跨渠道用，就把品牌信息想办法并进标题区，或者干脆横版另出一张。

导出之后：过一遍压缩

392 KB的PNG不必直接上传。转成JPEG或者WebP，画质0.8到0.85，体积能砍到二十分之一，肉眼看不出差别——这张图本来就是给人在信息流里扫一眼的。

版式：四选一其实是在选信息密度

四种版式里，左对齐留白和左侧色条的排版逻辑基本一致，差别只是左边多一根色条；居中大字把标题居中，适合只有一句话的图；引用式在标题上方加一个半透明的大引号，适合摘句。

从实用角度看，真正的区别不在好不好看，在你打算放多少字。居中大字在字多的时候最难读——居中排版每行起点都不一样，眼睛回扫成本高，三行居中的长标题在缩略图状态下几乎没法扫。字多就用左对齐那两种，字少（一句话以内）再考虑居中。

引用式还有个额外的注意点：那个大引号会把标题整体往下推，留给正文的纵向空间变少，所以它更不适合长标题。

发布之前：先预览

配好标签之后，用预览工具看一眼各平台实际抓到什么、裁成什么样。这一步能抓到的问题包括：图片地址写成了相对路径、图被放在登录墙后面、比例不对被裁掉关键内容，以及本文说的这几种断行意外。

常见问题解答

为什么我标题里的emoji在图上变成了两个方块？

因为断行点正好落在了这个emoji中间。工具是逐个UTF-16码元往下量宽度的，而emoji属于基本多文种平面之外的字符，在字符串里占两个码元。断行落在这两个码元之间，就会一半留在上一行、一半跑到下一行，各自渲染成一个替换字符方块。实测量过，两个半截的宽度都是69.93像素，跟替换字符本身完全一致，而完整的emoji是98.86像素。把emoji放在标题最开头可以规避，因为第一个字符永远不会是断行点。

英文标题为什么会从单词中间断开？

同一个原因：断行只看宽度够不够，不看词的边界。实测一个英文长标题会被断成Understanding Internationa、lization and Localization Re、quirements三行，两处劈在单词中间。Unicode的换行算法附件明确说过，字母类字符之间除非有空格这类字符提供断行机会，否则不允许断行；而汉字之间是可以随便断的。工具用的是后一套规则，所以页头那句中文自动换行说得其实很准确。

中文标题会有什么问题？

标点可能跑到行首。实测14个汉字加一个逗号的标题，第二行就是以逗号开头的。W3C的《中文排版需求》里有专门一节讲行首行尾禁则，逗号、句号、右括号这类不能出现在行首。浏览器渲染普通网页文字时会自动处理，但画布上的文字是逐行画的，排版引擎没有参与，这些规则得自己实现。解法是在输入框里手动按回车换行。

1080×1080的方图能直接发到横版大图卡片的平台吗？

能发，但右上角标签和左下角署名会被裁掉。实测扫描画布位置：标签在纵向76到116像素，署名在987到1008像素，而1.91比1的居中裁切只保留258到822这一段。标题和副标题在区间内活着，那两个角完全落在可见区之外。工具说明里那句版式已经预留了安全边距指的是7.5%的内边距，而跨比例裁切要切掉的是上下各23.8%，不是一回事。

为什么导出的PNG有将近400 KB？

因为这张图对PNG极不友好。实测1200×630导出401499字节，同样的画布内容编成JPEG是44328字节、WebP是21780字节，PNG是WebP的18.4倍。画布上有1541种不同颜色，一半来自背景右下角那团径向渐变，一半来自文字的抗锯齿灰阶。把渐变抹平后重新导出，PNG从401 KB降到181 KB。工具的导出格式是写死的，没有选项，建议导出后再过一遍压缩工具转成JPEG或WebP。

标题最多能写多少字，写满了会不会把署名压住？

主标题上限60字、副标题上限80字，两个都填满实测不会压住署名——内容最后一行底边在463像素，署名顶边在527像素，中间还空着64像素。副标题的绘制逻辑本身确实没有行数限制，把上限临时改大灌到240字才开始接触署名。所以真正在兜底的是那两个字数上限，不是绘制代码。

八组配色有没有对比度不够的？

没有。按WCAG公式实测：主标题压背景是13.04到18.88，副标题和署名压背景最低5.35，右上角标签最低4.02。标签那个4.02低于普通文字4.5比1的要求，但它是22像素700字重，符合标准里对大号文字的定义（至少18磅或14磅加粗，约合24像素或18.5像素），适用3比1的标准，达标。八组四个位置全部合规。

og:image标签除了地址还该写什么？

宽、高、类型和alt。Open Graph协议定义的子属性有og:image:url、og:image:secure_url、og:image:type、og:image:width、og:image:height和og:image:alt，其中alt最常被漏掉，它的定义是对图中内容的描述而不是图注。既然搜索引擎不会去认图里的字，alt就是这张图唯一能被机器读到的文字。另外要提醒的是，协议本身并没有规定任何尺寸、比例或体积上限，1200×630来自平台的裁切习惯而不是规范。

权威参考资料