Why WeChat covers need both 2.35:1 and 1:1 crops

Here is the short version: WeChat does not ask for both 2.35:1 and 1:1 covers by accident. The same article appears in different visual placements, and each placement favors a different crop. A wide crop works better for list cards and horizontal entry points, while a square crop is safer for thumbnail-style placements and asset reuse. For an automated publishing pipeline, uploading one original image is not enough; the draft is only truly review-ready when both crops are already prepared.

Many teams learn this the hard way. They assume that “the article has a cover image” means the cover step is done. In practice, the real question is not whether the image exists, but whether it survives multiple placements without breaking. A wide card may look fine in one view and cut off the product screenshot in another. A square thumbnail may be acceptable in one placement but look cramped in a horizontal card. For OmniGoAI's OmniPost, cover upload, cover cropping, and public publishing are three different layers of capability, and confusing them leads to bad operational decisions.

If you are also sorting out WeChat automation boundaries, these two related posts are worth reading first:

• https://omnigoai.com/en/blog/wechat-cover-auto-upload/
• https://omnigoai.com/en/blog/wechat-publish-vs-masssend/

Why one original image is not enough for a WeChat cover

Because the same article does not live in one UI container.

A WeChat article can show up in at least two very different visual contexts:

1. Horizontal list or card placements, where a wide frame communicates the topic faster;
2. Square thumbnail or asset-style placements, where a centered subject survives better.

If the platform only took one original image and cropped it everywhere automatically, the result would often be poor. The most common failures are easy to recognize:

• the person or product UI gets cut off in one crop;
• text embedded in the image becomes unreadable in another;
• the same article looks like two unrelated assets depending on where you see it.

That is why many content teams eventually realize the real requirement is not just “upload a cover,” but “prepare different crops for different placements.”

What do 2.35:1 and 1:1 each optimize for?

These ratios are not arbitrary design preferences. They map to different reading surfaces.

2.35:1 is safer for horizontal cards

A 2.35:1 image is a very wide frame. Its value is straightforward:

• it fits list-style cards and banner-like article entries better;
• it preserves horizontal compositions such as product UI, title areas, or multi-person scenes;
• on mobile lists, it reads as a proper content card instead of a square forced into a horizontal slot.

Operationally, the biggest advantage is not just aesthetics. A wide image is often better at communicating the article topic on first glance. If the cover contains a product screen, a keyword, or a workflow scene, the extra horizontal space carries more meaning.

1:1 is more stable for thumbnail-style placements

The square crop matters for a different reason: stability.

• some asset views and backend previews are naturally square-ish;
• a square crop makes it easier to keep the subject centered;
• if the same image is later reused elsewhere, 1:1 is one of the most portable ratios across platforms.

So the square crop is not a fallback. It is another first-class asset. If you only prepare the wide crop, square previews depend on the platform's emergency crop. If you only prepare the square crop, horizontal cards lose context and breathing room.

Why automation must handle both crops instead of delegating everything to the backend

Because once you leave cropping entirely to the platform UI, the result becomes unpredictable.

In a manual workflow, an editor can drag the crop box, test a different image, and fix the last mile by hand. In an automated workflow, that is exactly the kind of repeated work you are trying to remove. The promise of automation is not “the image got uploaded.” The promise is “the draft is already close to a final editorial state.”

From a pipeline point of view, dual-ratio cropping solves at least four real problems:

1. It reduces review-time rework. If both wide and square crops are already ready, the editor does not need to go back and repair the cover.
2. It keeps the asset visually consistent across entry points. The article feels like one content object, not two accidental screenshots.
3. It avoids default crop damage. The platform can crop geometry, but it cannot understand what the real subject is.
4. It makes agents and scripts reusable. Once the rule is encoded in the tool, the same workflow can run repeatedly without visual surprises.

This is the natural extension of the earlier point about automatic cover upload. Uploading the asset is only half the story. The more complete definition of “cover prepared” is: the image exists, the required placements are accounted for, and the editor does not need to rescue the result manually.

How is this different from automatic public publishing?

It is related, but it is not the same problem.

People often see “the tool can already crop the cover automatically” and conclude that “automatic public publishing should also be solved.” That conclusion is unsafe. Cover cropping belongs to the asset-preparation layer. Automatic public publishing depends on another boundary entirely: the WeChat API mode and the freepublish permission.

In other words:

• dual-ratio cropping solves whether the draft is fully prepared;
• automatic public publishing solves whether the article can go live as a public page;
• mass send is an even higher-impact distribution action.

Those layers should not be merged into one idea of “publishing.”

Where do teams usually get this wrong?

The most common mistakes look like this.

They validate the body, but not the cover across placements

A lot of automation checks only verify that the draft was created, the body is there, and the summary exists. That is not enough once the cover must survive multiple placements. The real checks are:

• does the wide crop preserve the subject?
• does the square crop still show the brand or topic clearly?
• do both crops keep the same visual focus?

They pass one large image and trust the platform to crop it well

That is the easiest setup and the least reliable one. The platform's default crop does not know what matters in your image. You may get lucky once, then fail badly the next day with a slightly different composition.

They confuse “uploaded successfully” with “ready to publish”

A successful upload only proves the asset entered the workflow. It does not prove that each placement looks right. For a content team, the difference is huge. A cover is not really finished until it exists, matches the required ratios, preserves the focal point, and needs no emergency manual repair.

What kinds of source images work better for dual-ratio cropping?

If you want one source image to support both 2.35:1 and 1:1, design it around a center-safe composition from the start:

1. Keep the main subject near the center. Elements placed too far left or right are the first to be lost.
2. Do not place important text at the edges. If your cover includes text, keep it inside the safe center area.
3. Prefer one clear subject or two well-grouped subjects. The more scattered the composition, the harder it is to make both crops work.
4. Keep logos, product windows, and key controls inside the center-safe zone. This matters a lot for software posts where the UI itself carries meaning.

That advice is not unique to WeChat, but WeChat's dual-crop requirement makes the problem visible much earlier, so it is worth designing for it on purpose.

What should an automation tool actually aim to do?

The right goal is not “upload the image.” The right goal is:

1. accept one source cover asset;
2. generate both 2.35:1 and 1:1 outputs for the relevant WeChat placements;
3. crop around the subject in a centered, damage-minimizing way;
4. make both assets available during the draft stage;
5. let the editor review something that already looks close to the final state.

That is also why OmniPost treats the cover as a structured publishing field instead of a disposable attachment. In a real content pipeline, the cover is part of click-through performance, platform fit, and editorial quality. It is not decoration.

A practical recommendation for content teams

If you are integrating WeChat into a content pipeline, I would recommend this checklist:

1. Treat “cover uploaded” and “both required crops are usable” as two separate acceptance checks. Do not assume one implies the other.
2. Design your cover templates around a center-safe zone. That gives one source image a better chance of surviving both 2.35:1 and 1:1.
3. Move dual-ratio cropping into automation, not into final editorial cleanup. Editors should decide whether the article is worth publishing, not keep fixing crop boxes.
4. Debug cover handling separately from publishing permissions. Bad crop? Check the asset and crop logic. Cannot go public? Check the API mode and publishing permissions.

Once those boundaries are clear, WeChat automation becomes much easier to operate. Draft preparation is one layer, cover completion is another, and public release is a separate permission question. Each layer can then be tested and improved on its own.

If you want to connect website publishing, WeChat draft preparation, and cross-platform distribution into one workflow, the OmniPost download page is here: https://omnigoai.com/en/download/omnipost/ . It works best as a local-first distribution tool that prepares content into a near-final editorial state, instead of just pushing raw article text into a backend.

FAQ

Why can't WeChat just use one original image everywhere?

Because the same article appears inside different visual containers. A platform-side default crop can only cut geometry; it cannot reliably preserve your real focal point across all placements. The two ratios exist to serve different surfaces.

Which ratio matters more, 2.35:1 or 1:1?

Both matter, but for different reasons. The wide crop serves horizontal cards and list entries better, while the square crop is more stable for thumbnail-style previews and asset reuse. Dropping either one degrades a real placement.

If dual-ratio cropping is solved, does that mean automatic public publishing is also solved?

No. Dual-ratio cropping is an asset-readiness problem. Automatic public publishing is a permission problem tied to the WeChat API mode and freepublish. They are separate capabilities.

What should a team optimize first?

If you are still fixing covers by hand, automate the dual-ratio cover step first. It is repetitive, it creates a lot of review-time rework, and it directly affects whether the draft feels complete. Once the cover and body are reliably prepared, adding public-publishing permissions becomes much more worthwhile.