Character limits have two numbers: building an ad preview around warnings and blocks

Tim Keen — Sat, 31 Oct 2026 23:49:48 +0000

Disclosure up front: I run Maestro, a B2B paid media company, and this post is about a free tool we built, the Maestro LinkedIn ad mockup. Nothing here needs you to use it. The problems are the same for anyone building a form, an editor or a preview against a platform's published limits.

The tool does one narrow job. You enter a LinkedIn single-image ad (company name, intro text, image, headline, optional description, CTA and destination URL), compare desktop and mobile views, and export a mockup plus a production brief for whoever approves the ad. It runs in the browser, needs no sign-in, and doesn't upload your creative.

Most of the interesting engineering wasn't in drawing the card. It was in deciding what the tool is allowed to say. This post walks through those decisions: how to model a limit, how to count characters when the platform doesn't tell you how it counts, how to show truncation you can't reproduce exactly, and how to test all of it.

A field has two limits, not one

LinkedIn's single image ad specifications publish two numbers for most text fields: a shorter length to avoid truncation and a hard maximum.

Field	Avoid truncation	Hard maximum
Introductory text	150 characters	3,000 characters (up to 10 emojis)
Headline	70 characters	200 characters
Description	100 characters	300 characters
Destination URL	n/a	must start with `http://` or `https://`; up to 2,000 characters
Ad name (optional)	n/a	255 characters

A single maxLength can't represent that. Set it to 3,000 and people ship intro text that gets cut off after the first line. Set it to 150 and you block copy LinkedIn would accept, which is worse, because the writer now has a tool telling them something false.

So the tool treats the two numbers as different kinds of rule:

Past the recommendation: show a warning. The copy may be fine. A longer intro can be a deliberate choice, and the writer decides.
Past the published maximum: block the review export until the field is fixed. This copy can't work.

That split, "you should look at this" versus "this can't ship", is the single most useful idea in the tool. It applies to any field with a soft and a hard limit: meta descriptions, SMS segments, push notification titles, app store subtitles.

Model the limit as data, with its source

Constants scattered through components break the first time the platform changes a number. Limits are facts with a source and a date, so they belong in one table that the UI, the validator and the export all read. Here's a simplified sketch of that shape:

type Severity = "warning" | "error";

type Rule = {
  field: "introText" | "headline" | "description" | "destinationUrl" | "adName";
  kind: "recommendation" | "maximum";
  limit: number;
  unit: "characters" | "emoji";
  source: string;      // URL of the published spec
  checkedAt: string;   // ISO date the spec was last read
};

type Finding = {
  field: Rule["field"];
  severity: Severity;
  count: number;
  limit: number;
  method: CountMethod;  // see the Unicode section
  message: string;
};

const severityFor = (rule: Rule): Severity =>
  rule.kind === "maximum" ? "error" : "warning";

Two details matter more than they look.

First, kind drives severity, not the number. Nobody has to remember that 150 is a warning and 3,000 is an error. A recommendation can never block, by construction.

Second, every rule carries checkedAt. Our page states that the limits were checked against LinkedIn's specs on September 27, 2026, and the exported brief carries the same date. If a refresh of the source fails, the honest state is "Unknown currency", not a silent pass on old numbers.

One green check is a lie: keep the states separate

The most common failure in review tools is a single status that quietly means several things. "Ready" might mean the preview renders, or the copy is within limits, or someone approved it, or the platform accepted it. Those are four different questions with four different owners.

The tool keeps them apart:

Preview: can the draft be pictured, with any missing fields labeled?
Technical check: do the supplied copy, URL and image pass the supported rules?
Production handoff: is the record complete enough for a named reviewer to check?
LinkedIn: has the intended Campaign Manager account supplied dated approval and native-rendering evidence?

Sketched as types:

type PreviewState = "Preview available" | "Preview incomplete";
type TechnicalState = "Pass" | "Needs changes" | "Unknown" | "Unsupported";
type HandoffState = "Ready for review" | "Hold";
type PlatformState = "Not checked" | "Externally verified";

type ReviewStates = {
  preview: PreviewState;
  technical: TechnicalState;
  handoff: HandoffState;
  platform: PlatformState;
};

Nothing inside the tool can set platform to "Externally verified". That value only arrives with dated, account-scoped evidence from someone who looked in Campaign Manager. A mockup can be ready for production review while LinkedIn is still Not checked, and the UI says exactly that instead of collapsing it into a checkmark.

If you build anything that previews a third-party platform, I'd start here. Write down which states your tool can know and which it can only record from someone else, and make the second group impossible to set from local code.

What counts as a character?

This is where most counters quietly go wrong. In JavaScript, "ðŸ‘ðŸ½".length is 4. A user sees one thing.

I ran a handful of strings through Node 20 to show how far the common methods drift apart:

Input	`.length` (UTF-16 units)	Code points	Grapheme clusters
`Hello`	5	5	5
`ðŸ‘`	2	1	1
`ðŸ‘ðŸ½` (thumbs up + skin tone)	4	2	1
`ðŸ‘©â€ðŸ’»` (ZWJ sequence)	5	3	1
`ðŸ‡ºðŸ‡¸` (regional indicator pair)	4	2	1
`Ã©` (precomposed)	1	1	1
`Ã©` (e + combining accent)	2	2	1
`1ï¸âƒ£` (keycap)	3	3	1

The two Ã© rows look identical on screen and count differently under two of the three methods. Normalizing to NFC first collapses the second one to length 1, which is worth doing before you count anything.

Grapheme clusters are the closest match to what a person thinks of as a character. Browsers expose them through Intl.Segmenter, which MDN lists as available across browsers since April 2024:

const segmenter = typeof Intl !== "undefined" && "Segmenter" in Intl
  ? new Intl.Segmenter(undefined, { granularity: "grapheme" })
  : null;

export function countCharacters(text) {
  const s = text.normalize("NFC");
  if (segmenter) {
    let n = 0;
    for (const _ of segmenter.segment(s)) n++;
    return { count: n, method: "grapheme (Intl.Segmenter)" };
  }
  return { count: [...s].length, method: "code point fallback" };
}

Note the return shape. The count travels with the method that produced it. If an older runtime falls back to code points, the export says so.

The part you can't know

Here's the honest problem: LinkedIn doesn't publish every detail of its Unicode counting logic. It says 150 characters "including spaces, emojis, and punctuation" and a limit of 10 emojis, but not whether a skin-toned thumbs up is one character or two.

So our count is a local review count, and the tool labels it that way. Copy that lands near a boundary gets a note to test it in Campaign Manager before launch. I'd rather show an honest "approximately 150, check natively" than a confident number that turns out to be wrong at exactly the point where it matters.

Counting emoji is its own trap

The 10-emoji limit needs an emoji detector, and the obvious regex doesn't agree with itself. Testing the same strings against two Unicode properties in Node 20:

/\p{Extended_Pictographic}/u matched ðŸ‘ and ðŸ‘©â€ðŸ’», missed ðŸ‡ºðŸ‡¸ and 1ï¸âƒ£, and matched a plain Â© with no emoji presentation selector.
/^\p{RGI_Emoji}$/v (the newer v flag) matched ðŸ‘, ðŸ‘ðŸ½, ðŸ‘©â€ðŸ’», ðŸ‡ºðŸ‡¸ and 1ï¸âƒ£, did not match a bare Â©, and did match Â©ï¸ with the variation selector.

The v-flag version is closer to what a person would call an emoji, but neither is guaranteed to match LinkedIn's rule. The approach I'd use: segment into graphemes first, test each grapheme, record the counting and emoji-sequence method in the export, and treat an emoji count near 10 as a boundary to check natively.

Truncation you can't reproduce exactly

The point of the 150 and 70 recommendations is truncation, so people want the preview to show where the "â€¦see more" lands. You can't get that exactly right from outside the platform. Truncation depends on fonts, viewport width, line height and rules the platform doesn't publish.

What we did instead:

Pick fixed, documented card widths. The preview uses a 552 CSS-pixel desktop card and a 358 CSS-pixel phone card inside a 390px model, and stays responsive down to 320px. Those are product decisions, written down, not claims about LinkedIn's layout.
Clamp by lines in CSS, not by slicing characters. Cutting the string at character 150 is wrong for two reasons: you might split a grapheme cluster, and the platform truncates visually, by lines. A line-clamp with a More/Less toggle is closer to the real behaviour and never corrupts text.
Keep the text selectable and complete. The collapsed state is presentation. The exported brief always contains the full copy, even when the preview is collapsed.
Label every export. Mockup images carry the caption "Approximate feed preview â€” check the final ad in Campaign Manager", plus the mode and variant. Production artwork is exported separately, with no card chrome or crop guides on it.

If a stakeholder screenshots the mockup and forwards it, the caption goes with it. That's cheaper and more honest than chasing pixel-perfect truncation.

Don't fake unsupported states

LinkedIn's spec says paid vertical (4:5) images serve on mobile devices only. A desktop/mobile switch could squeeze a portrait image into the desktop frame anyway, and it would look plausible. It would also show a placement that doesn't exist.

So the desktop view renders an explicit unsupported state for portrait creative. The same thinking applies to the description field. LinkedIn says the description shows on LinkedIn mobile and desktop when the image is less than 200 pixels wide, or when the ad runs beyond the feed through the LinkedIn Audience Network. For a normal large feed image, the tool doesn't promise the description will be visible.

A rule of thumb I took from this: if the honest answer is "this doesn't render here", render that answer. An empty state that explains itself is better than a convincing picture of something that won't happen.

Validate images against published ranges, and stop there

The image rules come from the same LinkedIn page:

Ratio	Recommended	Minimum	Maximum
Landscape 1.91:1	1200 Ã— 628	640 Ã— 360	7680 Ã— 4320
Square 1:1	1200 Ã— 1200	360 Ã— 360	4320 Ã— 4320
Vertical 4:5	720 Ã— 900	360 Ã— 640	2430 Ã— 4320

LinkedIn accepts JPG, PNG or GIF up to 5 MB. Our first version takes JPG and PNG only. Animated GIFs are rejected with a clear message rather than silently frozen on their first frame, because a frozen frame would misrepresent the ad.

Two things we deliberately did not do:

Infer a ratio tolerance. LinkedIn publishes rows, not a tolerance. Is 1200 Ã— 630 "close enough" to 1.91:1? The spec doesn't say, so the tool doesn't guess. It offers the recommended presets and Fit/Crop controls, and records the crop rectangle and focal point in the export.
Pretend our caps are LinkedIn's. The tool has its own limits, 5,000,000 bytes in and out and 24,000,000 decoded pixels, to keep the browser responsive. The UI calls them tool limits, not platform rules.

URLs: validate syntax, keep everything

Destination checks are simple on paper: an http:// or https:// prefix and up to 2,000 characters. LinkedIn also warns that some special characters in the query string, such as < > # % { } [ ], can cause errors.

export function checkDestination(raw) {
  const findings = [];
  let url;
  try { url = new URL(raw); } catch {
    return [{ severity: "error", message: "Not a valid URL." }];
  }
  if (!/^https?:$/.test(url.protocol))
    findings.push({ severity: "error", message: "Must start with http:// or https://." });
  if (raw.length > 2000)
    findings.push({ severity: "error", message: `Over 2,000 characters (${raw.length}).` });
  const query = raw.includes("?") ? raw.slice(raw.indexOf("?")) : "";
  if (/[<>{}\[\]]/.test(query))
    findings.push({ severity: "warning", message: "Query string contains characters LinkedIn says can cause errors." });
  return findings;
}

Note that the query check reads the raw string. new URL("https://x.com/?a=<b>").search comes back as ?a=%3Cb%3E in Node 20, so testing url.search would miss the characters the user actually typed.

Two cautions. Store the raw string exactly as entered, including every tracking parameter. Normalizing it through URL and writing back url.href can re-encode characters and change what gets launched. And syntax validity proves nothing about the page. The brief records the destination headline and next action separately, so a reviewer can judge whether the ad's promise matches the page.

Edits invalidate checks, presentation doesn't

Once there are reviews in the record, every edit raises a question: which checks does this edit invalidate?

We split inputs into two groups:

Content: image, crop, copy, CTA, destination and evidence. Changing any of these invalidates the checks and exports that depend on it, while unrelated evidence survives.
Presentation: desktop/mobile mode, collapsed/expanded copy, theme, crop overlay. Changing these changes what you see and nothing else.

One simple way to implement it: store, with each review, a hash of the content fields it covered. On edit, recompute the hashes and drop any review whose hash no longer matches. That's easier to reason about than event-driven invalidation, and it makes "why did my approval disappear?" answerable: the field it covered changed.

Import is all or nothing

Users can export a structured JSON record and import it later. The record embeds the original, delivered and logo image bytes with hashes, so a file that only contains a path isn't treated as lossless.

Import validates the whole record first: schema, embedded assets, hashes and size caps. Only then does it replace the current work, in one step. If anything fails, the current work stays as it was. A half-imported record is worse than a failed import, because it looks fine.

How to test it

These are the tests I'd write for any tool like this. Each one maps to a behaviour our tool's page commits to:

Boundary triplets for every rule. 149, 150 and 151 characters of intro text should give no finding, no finding and a warning. 2,999, 3,000 and 3,001 should give a warning, a warning and an error. Same pattern for 70/200 and 100/300. A 151-character intro must never produce an error.
A Unicode fixture file. The strings in the table above, plus the two forms of Ã©, run through countCharacters, with expected counts per method. When a runtime changes its segmentation data, this file is where you'll find out.
State-separation tests. Load the worked example, and no real approvals come with it. The sample ships with clearly labeled simulated review records, and loading it into the editor clears them, so it opens on Production handoff: Hold. Assert that no code path sets the platform state to verified.
Invalidation tests. Approve, change the headline, assert the copy review is gone and the asset review survives. Toggle desktop/mobile, assert nothing is gone.
Import round-trips. Export, import, and compare byte-for-byte. Then corrupt one embedded image hash and assert the import fails with the current work intact.

What I'd tell someone building one of these

Put limits in data, with the source and the date they were checked.
Give recommendations and maximums different kinds, so severity follows from type.
Count graphemes, say which method you used, and label the number as local.
Clamp visually, never slice strings, and caption every exported image as approximate.
Render unsupported states instead of plausible fakes.
Keep "we checked it" and "the platform accepted it" in separate fields that local code can't merge.

The tool isn't an official LinkedIn preview and can't predict approval, delivery or performance. It's a review step before Campaign Manager, and the final check still happens there. If you want to poke at the decisions above, the Maestro LinkedIn ad mockup is free and runs entirely in your browser.

Disclosure: I'm Tim Keen and I run Maestro, the B2B paid media company that makes the tool. LinkedIn limits in this post were taken from LinkedIn's single image ad specifications page; the tool's page records them as checked on September 27, 2026. Unicode results come from Node 20.

DEV Community: Tim Keen