SmsPrecheck is a paste-first check for a text message before you send it. You drop in the copy, and it returns a scored pre-check: carrier-filter vocabulary, segment and encoding costs, and whether the opt-out and consent text are present. I built it because SMS fails in two quiet ways — it gets filtered, or it costs four times what you expected because one emoji split your message into Unicode segments.

Carriers filter by pattern, so I filter by pattern

A carrier spam filter is a signal scorer, not a reader. It dislikes link shorteners, "STOP" buried at the end, urgency words, and sender IDs that look like a random number. Those are detectable. The core of SmsPrecheck is a vocabulary and structure ledger: it flags filter-prone phrases, checks that an opt-out mechanism is stated, and notes when consent language is missing. None of that needs judgment, so none of it uses a model — the model, if involved, only writes the one-line summary at the top.

The part people forget is encoding. GSM-7 covers most Latin text at 160 characters per segment. The instant you add an emoji or a smart quote, the message switches to UCS-2 at 70 characters per segment, and a 200-character message that was one SMS becomes three. That is pure arithmetic, and arithmetic is exactly what a model should not be doing when the bill depends on it.

What the report returns

Pre-check findings: the specific words and structures that raise filter risk. A segment and encoding breakdown: character count, encoding type, and how many billable segments result. Fix checklist: move the opt-out up, drop the short link, strip the stray emoji, or reword the urgency. Decision-support framing: the score is a reason to revise, not a promise the message delivers.

Delivery is never guaranteed. A clean report means your copy is not obviously fighting the filter and your billing is what you expect. It does not mean the carrier will not still throttle a new long-code sender.

A concrete example: a 180-character Latin message is one segment; add a single "✅" and it becomes UCS-2, dropping to 70 characters per segment, so your 180 characters now bill as three. Small teams get surprised by this constantly because the character counter in their phone does not show encoding. The breakdown makes the split visible before you send, not on the bill, which is the moment a fix is still free. The SmsPrecheck page is clear about that, because the tool removes the self-inflicted problems, not the carrier's behavior.

What it cannot see

It reads the text you paste. It cannot see your sender reputation, your 10DLC registration status, your throughput tier, or whether recipients opted in through the channel you think they did. Those usually matter more than wording. It also cannot predict a specific carrier's current filter, which shifts without notice, and it is text-only — a misleading claim in an attached image is invisible to it.

So the output is decision-support. The report is what you hand yourself before send: "here are the words to change and here is why this is three segments, not one". If deliverability is already shaky, the answer is registration and reputation, not copy — and the tool says so. The SmsPrecheck scan just makes sure the copy and the billing are not the part you skipped.

FAQ

What does SmsPrecheck measure?
Carrier-filter vocabulary, a segment and encoding breakdown (GSM-7 vs UCS-2), and whether opt-out and consent text are present.

Will a clean score guarantee delivery?
No. It removes copy-level and billing surprises. Sender registration and reputation still dominate delivery.

Can it verify recipients opted in?
No. It reads the pasted message only. Consent is a separate fact about your list.

Is this legal advice about TCPA or 10DLC?
No. It is a heuristic pre-check for decision-support. Confirm messaging-compliance questions with counsel.