DEV Community: charlie-morrison

Telegram's 4096-character limit isn't characters. I measured it

charlie-morrison — Mon, 10 Aug 2026 20:22:18 +0000

If you have ever asked how long a Telegram message can be, you have met the same answer twice: 4096 characters, and by the way Telegram counts UTF-16, so an emoji costs two. It is repeated in library issues, in Stack Overflow answers, and in the defensive splitters people paste into their bots, usually as a chunk size of 2000 or 4000 chosen with a shrug for safety.

I write a lot of bot code that emits long, emoji-heavy status blocks, and that folklore was costing me splits I did not think I needed. So I stopped guessing and asked the API directly: send messages one unit either side of the boundary, in four different alphabets, and see which measurement predicts what the server does.

The answer is that the number 4096 is real and exact, and that the unit almost everybody names is the wrong one. Worse, the UTF-16 rule is true, of a different field, in the same reply. A single Message object mixes two units, which is precisely why the folklore has survived so long: everyone is half right.

Unedited output from the probe, 10 August 2026. Every number in this post comes from this run.

How I tested it

The probe builds strings out of four deliberately different characters and sends each through sendMessage against a real bot token (a throwaway bot, never one serving users), recording the HTTP status and the exact description Telegram returns. Every message it manages to send is deleted with deleteMessage in the same breath, so the run leaves nothing behind in the chat.

The four characters are chosen so that the candidate units disagree with each other:

a -- 1 code point, 1 UTF-16 unit, 1 byte. All three units agree, so this only finds the number.
я -- 1 code point, 1 UTF-16 unit, 2 bytes. Separates bytes from the rest.
😀 (U+1F600) -- 1 code point, 2 UTF-16 units , 4 bytes. Separates code points from UTF-16.
e + combining acute (U+0301) -- 2 code points , 2 UTF-16 units, 3 bytes, and one thing you can see. Separates all of them from "visible characters".

Then the only discipline that matters: test the unit immediately either side of every candidate boundary. A limit you have bracketed to the nearest hundred is a limit you have not found.

The number is 4096. The unit is code points.

ASCII gives the number straight away. 4,096 characters go through; 4,097 come back as a clean 400 Bad Request: message is too long. No truncation, no silent trim -- a real error you can catch.

Cyrillic kills the bytes hypothesis. 4,096 Cyrillic characters are 8,192 bytes of UTF-8, twice the ASCII payload, and Telegram accepts them; 4,097 fails. So whatever is being counted, it is not the size of what goes on the wire.

The emoji case is the one that surprised me. If the cap counted UTF-16 code units, 2,049 emoji -- 4,098 units -- would be rejected. It was accepted. So I pushed until it broke, and the boundary sits exactly where a code-point counter would put it:

emoji x4096   code pts 4096   UTF-16 8192   bytes 16384   -> OK
emoji x4097   code pts 4097   UTF-16 8194   bytes 16388   -> 400 message is too long

Read that again, because it is the whole post. A single Telegram message can carry 4,096 emoji, 16 KB of UTF-8 and 8,192 UTF-16 code units, and the server takes it. I echoed the accepted message back out of the API response and compared it to what I sent: identical, character for character. Nothing was truncated on the way through.

The mixed case pins it from the other side. a × 4,095 followed by one emoji is 4,096 code points and 4,097 UTF-16 units: accepted. Add one more a and it is 4,097 code points: rejected. Across every probe I ran, "code points ≤ 4096" predicted the outcome every single time. "UTF-16 units ≤ 4096" did not.

But the UTF-16 rule is real -- for offsets

Here is why the folklore refuses to die. In the same JSON reply that just accepted 8,192 UTF-16 units, the formatting entities are indexed in UTF-16.

Send one emoji followed by bold text and read the entity Telegram hands back:

😀*bold*     ->  {"offset": 2, "length": 4, "type": "bold"}
😀😀😀*bold*  ->  {"offset": 6, "length": 4, "type": "bold"}

One emoji, and the bold run starts at offset 2. Three emoji, offset 6. If offsets were code points those numbers would be 1 and 3. Telegram documents this (entity offsets are specified in UTF-16 code units) and it is correct, and it has been quietly transplanted onto the length cap by a thousand summarised answers.

So both halves of the folklore are true of something. They are just true of different fields:

Field	Unit	Python equivalent
4096 text cap / 1024 caption cap	Unicode code points	`len(text)`
`entities[].offset` and `.length`	UTF-16 code units	`len(text.encode('utf-16-le')) // 2`

If you have ever sliced a message at an entity offset with plain Python indexing and watched the bold run land one character to the left for every emoji before it, that table is the bug.

Visible characters are not the unit either

The combining-mark probe closes the last escape route. e + U+0301 renders as a single é, but it is two code points. Send 2,048 of them, which is 2,048 things a human can see and 4,096 code points, and it is accepted. Send 2,049 and it fails at 4,098.

So a user can paste 2,049 visible characters into your bot and be told their message is too long, and they will be right and the error will also be right. If you show a live character counter in a Mini App, this is the case that makes it disagree with the server. Any counter built on grapheme clusters, or on String.length in JavaScript (which is UTF-16), will be wrong in one direction or the other for exactly these inputs.

Captions: same rule, different number, different error string

Captions cap at 1,024 and behave identically. 1,024 emoji, or 2,048 UTF-16 units, are accepted; 1,025 are rejected. Worth noting for log-grepping: the error text is not the same one sendMessage returns.

sendMessage  -> 400 Bad Request: message is too long
sendPhoto    -> 400 Bad Request: message caption is too long

A pleasant contrast with the file limits. When I measured the file size boundaries, an over-limit upload got no error at all -- Telegram dropped the TLS connection ~30 seconds in and left the caller holding a transport exception. Text is the well-behaved case: you get a real 400, immediately, with a description worth logging.

What this means in code

In Python, the naive guard is the correct guard. len(text) <= 4096 matched every outcome I measured. This is the rare case where the obvious thing is right and the clever thing, re-encoding to UTF-16 to "be safe", is what makes you wrong.

In JavaScript, the naive guard is the wrong one. str.length is UTF-16 code units, so an emoji reads as 2 and your Mini App will refuse a message the server would have accepted. Count code points instead: [...str].length, which iterates by code point and gives 1 per emoji.

Stop halving your chunk size for emoji. If you split long output at 2,000 "to be safe with unicode", you are sending twice the messages you need to, at twice the flood-limit risk, for a hazard that does not exist. Split at 4,096 code points.

Never index a string by an entity offset directly. Convert first: encode to utf-16-le, slice by offset * 2 and length * 2, decode back. Anything else is correct only until someone types an emoji.

Building on Telegram for something lighter?

My free planner lays out a Telegram game night -- rounds, timings, poll structure -- in about a minute, no signup.

Build a game night -> Or read how to run one end to end.

What I did not test

Three honest gaps. I did not test whether the same code-point rule holds on the MTProto client APIs -- TDLib and the user-account layer are a different code path where the UTF-16 convention is far more visible, so I would not assume my result transfers. I did not test editMessageText, only sendMessage and sendPhoto; I would expect the same cap but I have not seen it. And I did not probe the entity-count limit, which is a separate ceiling that bites long formatted messages before the length cap does.

Everything here comes from one bot on one network path. I am comfortable with that for this particular claim, because the result is not a statistical trend -- it is a boundary that lands on an exact power of two from four directions at once, with a one-unit failure on the far side of each. Encoding a message differently changed its byte length fourfold and moved the boundary not at all.

The short version

The cap is 4,096 Unicode code points , exactly. 4,097 gives 400 message is too long.
Not bytes: 4,096 Cyrillic characters are 8,192 bytes and go through fine.
Not UTF-16: 4,096 emoji are 8,192 UTF-16 units and 16 KB, and go through fine.
Not visible characters: 2,049 combining-accent é's are 4,098 code points and are rejected.
Entity offsets are UTF-16. Two units in one Message. Convert before slicing.
Captions: same rule at 1,024 , with a distinct error string.

Questions I had before I measured

What unit is Telegram's 4096 message limit counted in?
Unicode code points. Measured against a live bot, 4,096 code points is accepted and 4,097 is rejected with 400 Bad Request: message is too long, regardless of how those code points encode. A message of 4,096 emoji is 8,192 UTF-16 code units and 16,384 bytes of UTF-8, and it sends without complaint.
Does an emoji count as two characters in a Telegram message?
Not against the length cap. A non-BMP emoji is one code point, and the cap counts code points, so it costs one. It does count as two in entity offsets, which are measured in UTF-16 code units. That is why the advice to budget two units per emoji is half right: it applies to formatting offsets, not to the 4096 limit.
Is len(text) a correct check for the Telegram message limit in Python?
Yes. Python's len returns the number of Unicode code points, which is exactly the unit the cap uses, so len(text) <= 4096 matched every measured outcome. Guards written against UTF-16 length or UTF-8 byte length both reject messages that Telegram accepts.
Does the same rule apply to the 1024 caption limit?
Yes. Captions cap at 1,024 code points and behave identically: 1,024 emoji is accepted at 2,048 UTF-16 units, and 1,025 is rejected with 400 Bad Request: message caption is too long. The error text differs from the sendMessage one, which is useful when you are reading logs.

Telegram in Production -- the parts that bite you

The guards from this post, finished: a length check in the unit the server actually uses, an entity-offset slicer that survives emoji, and a splitter that stops halving your chunks for no reason. Plus the file-size guard that fails loudly instead of retrying forever, an initData validator with signature excluded and auth_date enforced, poll payloads Telegram will not silently rewrite, and a systemd unit linter for the two failure modes that cost me weeks. 55 tests you can run from the zip.

Get the pack -- $19 What is in the pack, module by module. Every claim in it was measured first and published here.

Telegram Poll Limits: What I Measured Against the Live Bot API

charlie-morrison — Tue, 04 Aug 2026 19:57:35 +0000

A game night in a group chat lives or dies on polls. They are the only mechanic Telegram gives you where twelve people can answer at once without the first reply telling everyone else what to think. Every round I have ever run -- who is lying, which answer is right, who gets the dare -- ends in a poll.

So it is worth knowing exactly where a poll stops working. Not the theory: the point where the API says no, and the more annoying point where it says yes and quietly does something else. I spent an evening sending deliberately-broken polls at Telegram until it complained, then read every poll back a second way to see what a person in the chat would actually get.

Some of it matches the official sendPoll reference. Three things do not, and one of those three has silently ruined a round for me before I understood it.

Unedited output from the three probe scripts, 3 August 2026. Every number in this post comes from these runs.

How I tested it

Three passes, because one was not enough to catch my own mistakes.

The first pass sends polls at the boundary of every documented limit -- a 300-character question and a 301-character one, twelve options and thirteen, and so on -- and records the exact accept or reject. The second pass re-sends the interesting cases and reads what Telegram echoes back in the response, because "accepted" and "sent as I asked" turn out to be different things. The third pass reads the same polls back over the client protocol with a normal user account, which is the closest I can get to seeing what a member of the group sees without asking anyone to look over my shoulder.

That third pass exists because of a habit I had to learn the hard way: an exit code of zero tells you the request left the building, not that the thing arrived intact.

The hard walls

These are the limits that produce a clean, immediate error. You will never hit them by accident with a short question, and you will hit all of them the moment you paste in something you wrote in a document.

What	Limit	What happens past it
Question	300 characters	poll question length must not exceed 300
Options per poll	12	poll can't have more than 12 options
Text per option	100 characters	poll options length must not exceed 100
Quiz explanation	200 characters	message is too long
Empty option	not allowed	text must be non-empty
Two identical options	allowed	accepted without complaint

Twelve is the number that shapes a game night more than any other. A round where everybody votes for a person -- who is most likely to lose their phone, who is bluffing -- caps out at a group of twelve, because each player needs their own option. Past that you are splitting the room into two polls and reconciling the counts by hand, which is exactly as fun as it sounds. If your group runs bigger than twelve, design the round as a vote on answers , not on people.

One hundred characters per option sounds generous until you write a Would You Rather. "Always have to say everything on your mind out loud, even in meetings" is 70. The version with the funny qualifier on the end is 118, and it is refused. The workaround is not to shorten the joke -- it is to put the full text in the message above the poll and keep the options to the two short labels people are choosing between.

The character cap counts characters, not bytes

This one I expected to go the other way. An option of 100 dice emoji is 400 bytes on the wire, and it is accepted. One hundred and one of them is refused with the same error as 101 letters.

So the cap is counted in characters as a person would count them, not in the storage a string takes up. That matters for anyone writing prompts with emoji in them, and doubly for anyone writing them in a language whose characters are multi-byte by default -- a Ukrainian or Greek option gets the same 100 characters as an English one, not half as many. The Unicode consortium's own FAQ is the reference for why those two counts differ so much in the first place.

Timers get rounded, not refused

Here is the behaviour that costs you a round. A poll can carry a countdown -- open_period -- and the allowed range is 5 seconds to 2,628,000 seconds, which is 30 days.

Send something outside that range and Telegram does not reject it. It silently rounds it into range and tells you nothing :

Ask for a 4-second timer, get 5 seconds.
Ask for 2,628,001 seconds, get 2,628,000.

The response comes back ok: true with the corrected number sitting in it, which is easy to miss if you are only checking that the call succeeded. And the corrected timer is real: I sent a poll asking for 4 seconds, waited nine, and tried to close it manually. Telegram refused -- poll can't be stopped -- because it had already closed itself on schedule.

The same forgiving-to-a-fault behaviour shows up in a second place. The documentation says open_period and close_date cannot be used together. Send both anyway and the request is accepted; the open_period wins and the close_date you specified is overwritten. I asked for a 60-second timer and a close time ten minutes out, and got a poll that closed in 60 seconds.

Why this bites in practice. Timed rounds are where hosts reach for these values, usually by computing them from something -- "close this when the round ends", "give them a third of the remaining time". Arithmetic that lands on 3 or 4 seconds silently becomes 5, and arithmetic that produces both a period and a date silently drops one of them. Nothing errors, nothing logs, and the round just runs on a timer you did not choose. Print the value Telegram echoes back, not the one you sent.

There is no bold, no italics and no spoiler inside a poll

Poll options carry no formatting at all. Not "limited formatting" -- none. I sent three options containing a spoiler tag, a bold marker and an HTML bold tag, then read the poll back over the client protocol. All three came back as literal text, with an empty entity list on every one of them.

The question field is only slightly better: it accepts a parse mode, but the reference restricts it to custom emoji entities. I sent a question as MarkdownV2 bold; the asterisks were consumed and the text arrived plain, with no bold and no entities. Not an error -- just quietly unformatted.

For a game night this rules out the trick everyone reaches for first: hiding the answer behind a spoiler tag inside the poll. ||like this|| in an option is displayed exactly as those characters, answer and all. What works instead is a two-part round -- the hidden text goes in a normal message, where spoiler formatting is fully supported, and the poll below it carries only the plain-text choices. It is one extra message and it is the difference between a reveal and a leak.

Quiz mode: one correct answer, whatever the field name suggests

Quiz polls -- the mode Telegram introduced with Polls 2.0 -- mark one option right and can show an explanation when someone picks wrong. The parameter is now named in the plural, correct_option_ids, which reads like an invitation to mark two answers correct.

It is not. Passing two ids is refused with QUIZ_CORRECT_ANSWERS_TOO_MUCH. The older singular parameter still works and comes back echoed in both the singular and plural fields, so nothing you already wrote is broken -- but a quiz round with two acceptable answers has to be built as two separate questions.

Two smaller findings from the same pass. A quiz without a correct answer is refused outright (correct quiz option list must be non-empty), so you cannot use quiz mode purely for its nicer layout. And the explanation is documented as allowing at most two line breaks -- I sent three and it was accepted, which is the one place the API turned out to be more permissive than its own description rather than less.

Four switches worth knowing before your next round

While checking the limits I went through the full parameter list, and a few of the newer ones solve group-chat problems I had been solving by hand:

hide_results_until_closes -- nobody sees the tally until the poll closes. This is the native fix for the single biggest problem with voting in a group: the first three votes anchor everyone who comes later.
shuffle_options -- each person sees the options in a different order, which kills "the answer is always the long one" pattern-matching in a quiz.
allows_revoting -- on by default for regular polls, off by default for quizzes. If your round is scored, turn it off explicitly and stop arguing about who changed their vote.
allow_adding_options -- lets players add their own answers, which is a genuinely good "make up a lie" round. It refuses to work on an anonymous poll: pair it with public voting or you get ANONYMOUS_OPEN_INVALID.

An honest caveat on the first two: Telegram accepts both flags, but neither appears in the poll object it sends back, and neither showed up when I read the poll over the client protocol either. So I can confirm they are accepted -- I cannot confirm from the response alone that they took effect. Set them, then look at the poll in the chat before you build a round around them.

Want the run sheet instead of the API?

The free Telegram Game Night Planner builds a timed game night as paste-ready blocks -- rounds, host lines, and poll questions with the options already separated so you can send them straight into a group chat. No signup, runs in your browser.

Build a game night -> Everything above is baked into the blocks it gives you -- short options, plain text, no spoiler tags where they will not render.

What I actually changed after this

Four rules, all of them the direct consequence of a probe above:

Options stay short and plain. The long version of the prompt goes in the message; the poll gets the two or three word labels. This sidesteps the 100-character wall entirely and reads better on a phone.
Nothing hidden ever goes in an option. Spoilers live in a normal message above the poll, because inside one they are just punctuation.
Twelve is the room size for person-voting rounds. Bigger group, different round design -- vote on the answer, not the player.
Read back the timer. If a round is timed, use the number Telegram returns, not the one that was sent. It is the only way to notice a clamp.

None of this is exotic. It is the difference between a round that lands and a round where somebody says "wait, I can see the answer" -- which, in a group chat, is the whole game.

Running a whole night, not a single round?

The Telegram Party Pack is the hosted version of everything above: 255 prompts across six games, a host guide for a 60-minute night in a group chat, and the poll, spoiler and threading mechanics laid out per round so nothing leaks and nothing anchors. Copy-paste blocks, PDF included.

Get the pack -- $9.99 The planner above stays free. See what is in the pack before you buy.

FAQ

How many options can a Telegram poll have?

Twelve. The thirteenth is refused with "poll can't have more than 12 options". A single-option poll is also accepted, which is occasionally useful as a one-button prompt. For any round where each player needs their own option, twelve is your real group-size cap.

How long can a poll option be?

100 characters per option, 300 for the question, 200 for a quiz explanation. The count is per character, not per byte -- 100 emoji weigh 400 bytes and still pass, while 101 of anything fails.

Can I use bold or a spoiler in a poll?

No. Options carry no formatting entities at all, so markup appears verbatim. The question accepts a parse mode but only for custom emoji -- bold sent as MarkdownV2 arrives stripped. Put hidden text in a regular message and use the poll only for the vote.

How long can a poll stay open?

From 5 seconds to 30 days. Anything outside that is rounded into range without an error, so a 4-second timer quietly becomes 5. Sending an open_period and a close_date together is also accepted despite the documentation, and the open_period is the one that wins.

13 Telegram Bots on One 1GB VPS: The Real RAM Numbers

charlie-morrison — Mon, 03 Aug 2026 20:25:21 +0000

Every thread about hosting a Telegram bot answers the same question with the same shrug. How much server do I need? -- "not much", "a small VPS is fine", "1 GB is plenty". Nobody posts numbers. So people either overbuy a 4 GB instance for a bot that answers six commands, or they pick the cheapest box on the market and spend a weekend wondering whether it will fall over.

I have thirteen Telegram bots running right now on a single 1 GB, 1 vCPU VPS that costs $4.17 a month. Some are mine, some are client work, one is a staging copy. Instead of guessing, I measured every one of them. Here is what a Telegram bot actually costs in memory, what the real ceiling turned out to be, and the thing on my box that quietly used more RAM than all thirteen bots combined.

Live readings from the box, 1 August 2026. Client bot names replaced with generic labels; every number is unedited.

What is actually on the machine

The host is a 1 vCPU / 1 GB / 24 GB NVMe instance. Linux reports 961 MB usable after firmware reservations, which is the number worth planning against -- not the 1024 you paid for. Thirteen tg-* systemd services are active: a media-downloader bot, seven demo and sales bots for a Telegram SaaS product, four client bots, and one staging duplicate.

All of them are Python, all use long polling rather than webhooks, and each one is a separate systemd unit with its own token and its own process. That last detail matters more than it sounds like it should, and I will come back to it.

What a Telegram bot really costs in RAM

Reading resident set size straight out of /proc/<pid>/status for each service's main PID:

Bot	Resident memory	What it does
Media downloader	21.0 MB	Fetches and returns media files
SaaS demo ×5	16.6-17.8 MB	Full menu, database, payments
Sales / signup bots	16.5 MB	Forms, notifications
Client bot A	16.2 MB	Team workflows
Client bot B	10.1 MB	Command-driven
Client bot C	9.9 MB	Command-driven
Client bot D	7.4 MB	File uploads
Client D staging	3.2 MB	Idle duplicate

Thirteen bots, 185.0 MB total, averaging 14.2 MB each. The whole fleet fits in under a fifth of a 1 GB machine.

The spread is the interesting part. The lightest bot uses 3.2 MB and the heaviest uses 21.0 MB -- a 6.5× range -- and that gap has almost nothing to do with how many users each one serves. The staging bot at 3.2 MB and the client bot at 7.4 MB run the same framework as the 17 MB SaaS bots. What separates them is what they import.

A bot that only parses text commands loads the Telegram library and little else. A bot that pulls in an HTTP client, a database driver, an image library and a payments SDK pays for every one of those at startup, whether a user ever triggers that code path or not. Python's memory floor is set at import time, not at request time. If you want a cheaper bot, the lever is your dependency list, not your user count.

One honest caveat about these numbers. RSS counts shared memory pages once per process. Thirteen Python processes on the same host share a lot -- the interpreter itself, libc, and any identical library versions -- so summing RSS overstates the true combined footprint. The real figure is somewhat below 185 MB. I am quoting the pessimistic number deliberately: if you plan against it you will not be surprised, and it is the number you can reproduce yourself in one command. The kernel's proc documentation spells out what each field does and does not include.

The biggest memory consumer was not a bot

This is the part that changed how I think about small hosts. Sorting every process on the box by memory, the top entry is not a Telegram bot at all:

Process	Resident memory
warp-svc (networking daemon)	162.8 MB
node	74.6 MB
systemd-journal	49.0 MB
All 13 Telegram bots combined	185.0 MB

A single networking daemon I installed once and forgot about uses 162.8 MB -- roughly 88% of what all thirteen bots use together , and about eleven average bots' worth of memory. Add node and the journal and the non-bot overhead comfortably exceeds the entire fleet.

So the mental model most people bring to this is backwards. When someone asks "can my 1 GB VPS handle another bot?", the honest answer is that one more bot costs about 14 MB and is almost never the problem. The thing to audit is everything on the box that is not a bot: the monitoring agent, the VPN client, the container runtime, the log daemon with no retention limit. That is where a 1 GB machine actually goes.

The real ceiling is not memory

Here is the number I am not going to dress up. The box shows 687 MB of RAM in use and 1041 MB of swap in use. It is over-committed, and it has been for a while.

It has also been up for 45 days with a load average of 0.52, 0.17, 0.05, and the media bot has recorded zero restarts. Nothing is falling over. What that combination means is that a pile of memory has been paged out to disk and is simply never touched again -- idle bots holding startup allocations they will not read a second time. On NVMe, that is a reasonable trade rather than a crisis, and it is exactly the behaviour Linux is supposed to produce.

But it does define the actual limit. When the constraint arrives, it will show up as latency, not as an out-of-memory kill: a bot whose pages have been swapped out takes a beat longer to answer the first message after a quiet spell. On one vCPU, the thing to watch is several bots waking simultaneously -- a shared burst is a CPU and paging problem, never a headline RAM problem.

Two practical consequences I would apply to any small box:

Cap the journal. An uncapped systemd journal grows until it owns real memory and real disk. Setting a size limit is a one-line change and buys back more than a bot's worth.
Set per-service memory limits. systemd will do this for you with MemoryMax= in the unit file, so one leaking bot degrades itself instead of the twelve next to it. The options are documented in systemd's resource-control manual.

One process per bot, and why it is worth it

Thirteen separate services is not the most efficient arrangement available. I could run several bots in one process and share an interpreter, saving maybe 100 MB of the 185.

I do not, and the reason is that the 100 MB is not the scarce resource -- my attention is. When a client bot crashes on a bad update, it crashes alone. systemd restarts that one unit, the other twelve never notice, and the journal tells me exactly which one it was. Sharing a process to save memory I am not short of would trade a resource I have for a failure mode I would have to debug at two in the morning.

The same reasoning drives long polling over webhooks. Webhooks are more efficient at scale and need one HTTPS endpoint rather than thirteen open connections. But they also need a public certificate, a reverse proxy and a working DNS record before a single message is delivered -- and every one of those is a thing that can break independently. Long polling, described in the official Telegram Bot API documentation, needs none of it: the bot dials out, so it works behind any firewall and needs no inbound access at all. At my volume that trade is obvious. Past a few hundred messages a second it flips, and python-telegram-bot's documentation covers both modes if you need to switch.

Measure your own box in one command

Nothing above required special tooling. To get the same table for your own server:

systemctl list-units 'tg-*' --state=active --no-legend --plain gives you the running units; for each one, systemctl show -p MainPID --value <unit> gives the PID, and grep VmRSS /proc/<pid>/status gives the memory. Then run ps -eo rss,comm --sort=-rss | head -- that second command is the one that matters, because it is what showed me the 162.8 MB daemon I would never have suspected.

If you are sizing a box before you build anything: budget about 15 MB per bot, then add up everything else you intend to install, and let the second number drive the decision. On this evidence a 1 GB instance holds well over thirty typical bots on memory alone. It will run out of CPU, patience, or forgotten background daemons long before it runs out of RAM.

See a Mini App that needs no server at all

The cheapest bot to host is the one with no backend. My party game ships its logic inside the page Telegram opens -- 151 questions per language, English and Ukrainian, no signup, nothing to switch off.

Open the Party Game No Telegram? It runs in a browser too: charliemorrison.dev/party-game

Not here to run a server?

If you landed on this because you wanted a game night rather than a hosting bill, The Telegram Party Pack skips the infrastructure entirely: 255 prompts across six games, rewritten for a group chat, plus a host guide covering polls, spoiler reveals and keeping a round legible when replies arrive out of order. Files you own -- no server, no uptime, nothing to maintain.

Get the pack -- $9.99 The Mini App above stays free, no signup. See what's in the pack before you buy.

FAQ

How much RAM does a Telegram bot need?

On this server a long-polling Python bot settles between 3 MB and 21 MB resident, averaging 14.2 MB across 13 bots. The variation tracks what the bot imports rather than how many users it has -- an HTTP client, a database driver and a media library cost more at startup than any amount of traffic does at runtime.

Can I run multiple Telegram bots on one 1 GB VPS?

Yes. Thirteen bots here use 185 MB in total, under a fifth of the machine. Memory is rarely the binding constraint -- a single vCPU during simultaneous bursts, and non-bot daemons, both bite first.

Does each bot need its own server?

No. Each needs its own process and token, but one host handles many. A separate systemd service per bot on one machine gives you crash isolation without paying for separate servers.

Long polling or webhooks?

Long polling is cheaper and much simpler: no public endpoint, no certificate, no reverse proxy, and it works behind any firewall because the bot dials out. Webhooks win when you have high volume and already run a web server. At thirteen low-traffic bots, polling is not close to being the bottleneck.

I Sent 24 Requests to Telegram's Bot API to Find What Breaks a Group Game

charlie-morrison — Wed, 29 Jul 2026 20:19:19 +0000

Every article about Telegram games answers the same question: which games. Truth or Dare, Never Have I Ever, Would You Rather, Most Likely To. Fine: that part is easy, and I've written one of those lists myself.

Nobody writes about the part that actually decides whether your game night survives past round three: the chat mechanics. A group chat is not a living room. Nobody takes turns. The person who types fastest answers first and quietly sets the answer everyone else copies. Half the group is reading on a phone under a table. The host, meaning you, is trying to run a game in a medium that has no concept of "whose turn it is".

Telegram has real tools for this: polls, quiz polls, spoiler text, pinned messages, self-closing rounds. Most of what's written about them is copied from other articles, and a fair amount of it is simply out of date. So rather than trust it, I sent 24 live requests to Telegram's own API : real polls, real spoilers, real pins, and I wrote down exactly what came back.

Seven of the 24 failed. Two of them "succeeded" while doing something other than what I asked, which is worse, because those are the two you ship to your friends without noticing.

How I tested it

I run a party game on Telegram, so the questions weren't hypothetical: I wanted to know which of these mechanics I could rely on when a group of eight people is mid-round and impatient.

The method was deliberately boring. Each mechanic became one request to Telegram's Bot API, using sendPoll, sendMessage and pinChatMessage, with one variable changed at a time: a poll question at 300 characters and then at 301, an option at 100 and then at 101, a quiz with a correct answer and then without one. Whatever the API returned, success or error, went straight into a results file. The screenshot below is generated from that file, not typed by hand.

All 24 requests. Green rows were accepted; red rows carry Telegram's own error text. The two red rows with code 200 are the dangerous ones.

One thing I could not test, and won't pretend otherwise: the per-group rate limit. My test account is restricted from creating new groups, so the requests went to a one-to-one chat with my bot, where 22 back-to-back messages went through in 6.1 seconds without a single block. That number does not transfer to a group. Telegram's own bot FAQ puts the guidance at roughly 20 messages per minute in the same group, and everything I say about pacing below follows their figure, not mine.

The five things that break a round

1. The 100-character option cap hits the exact game you most want to poll

A poll question can be 300 characters. Each option can only be 100. I got poll options length must not exceed 100 at 101 characters, and success at exactly 100.

That sounds generous until you look at what you're actually pasting. I ran all 255 prompts from my own game pack through those two limits. Zero exceeded the question cap. Twenty exceeded the option cap, and 19 of those 20 were Would You Rather.

Which makes sense once you see it. A Would You Rather line is already a question plus its two answers glued together: "Would you rather have unlimited money but no free time, or unlimited free time but just enough money?" runs to 138 characters. Paste that whole line as an option and Telegram rejects it. Would You Rather is the game that maps most naturally onto a poll, and it's the one whose text most reliably breaks the poll.

The fix is a split, not an edit. The dilemma goes in the poll question (300 characters, so it always fits; my longest was 101). The two halves become the two options: "Money, no time" / "Time, no money". When I re-ran the same 30 Would You Rather prompts that way, all 30 fit , without cutting a single word.

Host shortcut: if a prompt is too long to be an option, it was never an option. It was a question with the answers written into it. Split it, don't trim it.

2. The option limit is 12, not the 10 you'll read everywhere

Twelve options were accepted and created normally. Thirteen came back poll can't have more than 12 options. A lot of current advice still says ten, which was true of an earlier version of the API and quietly stopped being true.

This matters for exactly one thing, and it's the most popular game in the genre: Most Likely To. You want one option per player, so the group can vote for each other. Twelve options means a group of up to twelve fits in a single poll. At thirteen people you either split the vote across two polls, which fractures it, or drop the poll and take answers as replies.

3. Quiz mode demands a right answer, so it's wrong for opinion games

A quiz poll without a designated correct option is rejected: correct quiz option list must be non-empty. With one, it works, and you can attach an explanation that pops up after the vote.

So quiz mode is for trivia, where there genuinely is a correct answer, and the explanation slot is the best feature nobody uses: it lets the poll teach instead of just scoring. For anything with no right answer (Would You Rather, Most Likely To, Never Have I Ever) you want a regular poll. Reach for quiz mode there and Telegram forces you to declare one of your friends' opinions officially correct.

4. Polls are anonymous by default, which silently kills Most Likely To

Anonymity is the default, and that default is exactly backwards for half these games.

Never Have I Ever wants anonymity. People answer honestly precisely because nobody sees who tapped "I have". Most Likely To wants the opposite: the accusation is the game. "Most likely to reply at 3am: Ann, Bo, Cy" is only funny if you can see that four people voted for Bo. Run it anonymously and you get a bar chart, which nobody laughs at.

Turning anonymity off is one toggle when you create the poll, and it's the single highest-value decision in the whole session. My rule: confessions anonymous, accusations public.

5. Two requests that succeed while doing the wrong thing

These are the two red rows carrying code 200, and they're the reason I ran this test at all. An outright rejection you notice immediately, a silent substitution you ship.

Spoiler formatting is ignored inside a poll question. Telegram introduced spoiler text in 2021, and it's the mechanic that finally makes hidden-answer games work in a chat: the answer sits there covered until someone taps it. Write a poll question as Guess: ||Bo|| expecting the name to be hidden, and the API returns success, then delivers the question with the pipes visible as ordinary characters. The answer isn't hidden. It's printed, in a slightly uglier font, to everyone.

Spoilers only work in ordinary messages. So the pattern is two messages, not one: poll first, reveal second, spoiler applied to the reveal.

Bots cannot schedule anything. I sent a message with a scheduling timestamp one hour in the future. The API said success and delivered it instantly. My "scheduled" message arrived 3,599 seconds before its own schedule. There is no scheduling parameter for bots; the API just ignores what it doesn't recognise instead of telling you.

Scheduling does exist, in the Telegram app, on your side: compose the message, hold the send button, pick a time. That's how you have the rules card land in the group at 20:00 without being awake for it. It is not something you can automate through a bot, and if a tool promises you that, it is doing something else.

Two mechanics worth adding on purpose

Self-closing rounds. A poll can carry an open period. I set 30 seconds and it was created with a 30-second life. This is the closest Telegram gets to a turn timer. It ends the round for you, so the game doesn't die of one person "answering later", and it applies pressure that makes answers funnier.

Pin the rules, then edit the pin. Pinning worked, and so did editing the text of an already-sent message. Together those are a live scoreboard: pin one message at the start, edit it as the night goes, and anyone arriving late reads the current state instead of scrolling. Editing a pin doesn't re-notify the group, so it's cheap to update often.

One thing the API will not do is protect you from a broken round. A poll with a single option was accepted without complaint: a poll nobody can meaningfully vote in, delivered with a cheerful success code. Telegram checks lengths and counts. It does not check whether your game makes sense.

The host protocol this adds up to

Strip out the API detail and what's left is a short list of things a host does, all of which exist because the medium has no turns:

Name one host per session. Not a rotation, not a democracy. One person sends the prompts and closes the rounds, because otherwise two people post round four simultaneously and the thread splits.
Pin the rules, including the pace. "One round every ten minutes, replies by reply-thread." Half the failures aren't disagreement, they're people guessing at the tempo.
Poll first, talk second. A poll captures everyone's answer before the loudest voice anchors it. In an open-text round the first reply becomes the template for every reply after it.
Two passes each, then the round closes. The single rule that keeps quiet people in the game. It caps the extroverts without singling anyone out.
Space the sends. Around 20 messages per minute to one group, per Telegram's guidance. Twelve prompts fired back to back is also just unreadable.
Spoiler the reveals. Separate message, spoiler applied there, never in the poll question.

None of this is clever. It's just the set of things that turn out to be load-bearing once you stop assuming a group chat behaves like a room.

Try the free game first

Truth or Dare, Never Have I Ever and Would You Rather, with 151 questions per language, English and Ukrainian, no signup and no backend that can be switched off. Open it in the chat and start a round.

Open the Party Game No Telegram? It runs in a browser too: charliemorrison.dev/party-game

Want the rounds already built for polls?

The Telegram Party Pack is the version of this with the work done: 255 prompts across six games, each written to fit inside Telegram's limits, plus poll-ready files where the Would You Rather dilemmas are already split into question and options, the exact split this test says you need. Includes the host guide: pinned rules, pacing, spoiler reveals and keeping a round legible when replies arrive out of order.

Get the pack — $9.99 The game above stays free, no signup.

FAQ

How many options can a Telegram poll have?

Twelve. Tested directly: 12 options were created normally, 13 came back poll can't have more than 12 options. Plenty of guides still say ten, which was true of an older API version. The question is capped at 300 characters and each option at 100.

Why can't I see who voted in my Telegram poll?

Because polls are anonymous unless you say otherwise, and most people never change it. For accusation games like Most Likely To that's fatal, because seeing who picked whom is the game. Turn anonymity off for those, leave it on for confession-style rounds where hiding the vote is what makes people honest.

Can I schedule game-night messages from a bot?

No. The Bot API has no scheduling parameter and doesn't complain if you invent one. My message with a timestamp an hour ahead was delivered immediately with a success code. Scheduling lives in the Telegram apps: compose, hold send, pick a time.

Do spoiler tags work inside a poll question?

No. Formatting is ignored in poll questions, so ||spoiler|| arrives with the pipes visible and nothing hidden. Send the poll, then reveal the answer in a separate message with the spoiler applied there.

Which games work best as polls, and which as plain messages?

Polls suit anything with fixed choices: Would You Rather (split into question and options), Most Likely To (one option per player, up to twelve), Never Have I Ever (two options, kept anonymous). Plain messages suit anything open-ended, such as Truth or Dare, Story Chain and Paranoia, where the answer is written, not chosen, and the spoiler reveal does the work.

I Messaged 18 'Best' Telegram Game Bots. 7 Never Replied

charlie-morrison — Mon, 27 Jul 2026 22:21:54 +0000

Search for something like "best Telegram games" and you'll get a dozen confident listicles. Each one hands you a set of @handles: Hangman, 2048, Werewolf, Poker, Snake. What none of them tell you is which of those bots is still running.

That's not a nitpick. I run a Telegram game myself, and in May 2026 I switched off the chat-command backend behind it. The bot account stayed. Its profile page kept loading. My own article kept telling readers to add it to a group and type /play — into total silence, for weeks, before I noticed. Nobody complained, because a dead bot doesn't produce a complaint. It produces nothing.

So I stopped guessing and measured it. I took every bot recommended by three "best Telegram games" articles currently ranking on Google, sent each one a real /start from a real Telegram account, and waited to see what came back.

Eleven answered. Seven said nothing at all.

How the test worked

I wanted this to be boring and reproducible rather than clever, so the method is exactly what a person would do by hand — just automated so all 18 got identical treatment.

The sample is the union of the bots recommended by three articles ranking for "best Telegram game bots" in July 2026: a 16-game roundup on LightXtremeVPN, MakeUseOf's "8 Fun Telegram Game Bots You Should Try", and Membertel's "5 best Telegram Game Bots". Deduplicated, that's 18 distinct handles. I didn't hand-pick them and I didn't drop any.
The probe is one message: /start, the command every Telegram bot is expected to handle, sent from my own account (@charliemorrison) rather than a fresh burner, so nothing could be blamed on an unusual account.
The wait is 15 seconds. That is extremely generous — a live bot replies in well under a second, because the reply is a program responding, not a person typing.
The verdict is based on new inbound messages only. I record the newest message ID in the chat before sending, then count only replies newer than that. Otherwise an old message from a previous visit would make a dead bot look alive — which, on two of these chats, it would have.
Pacing: 6–11 seconds of randomised delay between bots, so the run looks like a person poking around rather than a flood.

Here is the actual run:

The real output. 15 seconds of patience per bot, 18 bots, no cherry-picking.

The seven that said nothing

Bot	Listed as	Result
@PlayGame2048Bot	2048 Puzzle	Silent
@Snakeslite_official_bot	SnakeLite	Silent
@HangBot	Hangman	Silent
@dreamersbot	Dreamers	Silent
@ArenaGameTelegramBot	Arena Game RPG	Silent
@chessybot	Chessy	Silent
@LumberjackBot	Lumberjack	Silent

Every one of those handles resolves. Open any of them in Telegram and you get a normal-looking bot profile with a name and a Start button. Press Start and the chat stays empty. There is no error, no "this bot is no longer available", no hint that you're talking to a switched-off machine. The most common reaction to that is to assume you did something wrong.

Worth flagging: Lumberjack is a special case that shows exactly how these lists rot. The standalone @LumberjackBot is silent — but LumberJack the game is still perfectly playable, because it lives inside @gamebot, which answered immediately. One article recommends the working route, another recommends a handle that leads nowhere, and both describe the same game. If you followed the second one you'd conclude the game is gone. It isn't.

The eleven that answered

These replied within the window, most of them instantly: @gamebot, @ChessBot, @xoBot, @unobot, @QuizariumBot, @wordibot, @RatherGameBot, @werewolfbot, @chat_against_humanity_bot, @PokerBot and @Gamee.

Two details are worth having before you pick one:

Several are group-only, and that surprises people. Quizarium's reply to a private /start is: "Yes, it's my command, but you can use it only within a group chat." Chat Against Humanity says the same in different words — you need a group and a couple of friends before anything happens. Not broken, just not a solo experience, which most roundups fail to mention.
@unobot's own first message points somewhere else: "Also check out @UnoDemoBot, a newer version of this bot with exclusive modes and features." The bot itself is telling you the recommendation is a version behind.

One caveat I'd rather state than hide: this is a snapshot taken on 28 July 2026. A bot that answered today can go quiet next month — that is the entire point of the exercise. Treat the list as a demonstration of the method, not as a permanent verdict.

Why bots die quietly

The reason is structural, and once you see it you can predict which recommendations will rot.

A Telegram bot is not a self-contained thing living on Telegram's servers. It's the Telegram-facing half of somebody's software. The platform's own documentation is blunt about the other half: "In order for a bot to work, set up a bot account with @BotFather, then connect it to your backend server via our API." That backend is a machine someone rents, maintains and pays for every month.

When the developer moves on — new job, lost interest, hosting bill no longer worth it — they stop paying for the server. They almost never delete the bot account, because deleting it takes deliberate effort and produces no benefit. So the account outlives the product. Telegram keeps rendering the profile from its own records, and your Start button keeps sending commands into a machine that is no longer there.

This isn't unique to Telegram, it's just unusually invisible there. Pew Research Center's 2024 study on digital decay found that "a quarter of all webpages that existed at one point between 2013 and 2023 are no longer accessible", and that 38% of pages from 2013 are gone. On the web, decay at least announces itself with a 404. A dead bot has no 404. It has an empty chat.

Which means 39% silent in this sample isn't a scandal — it's roughly what a decade of link rot looks like when it's applied to software that nobody can see rotting. The scandal is that lists keep recommending them without ever pressing Start.

The bug in my own test that nearly produced a fake result

I'll include this because it's the most useful thing I learned, and because the first version of this article would have been wrong.

My first run died four bots in. Everything after @ChessBot came back with the same error — TypeNotFoundError: Could not find a matching Constructor ID — and the naive reading was that 12 bots were unreachable. That would have been a much more dramatic headline and completely false.

What actually happened: my client library (Telethon 1.43.2) was receiving live account updates in the background, including an unrelated spam broadcast that used a newer Telegram data type than the library knows about. One unparseable object killed the connection's receive loop, and every later call inherited the corpse. The bots were fine. My tooling was lying to me.

The fix was one argument — receive_updates=False, so the server never pushes those updates to this client at all — and re-running gave clean results for 15 of 18. The last three still errored, so I re-probed those with a fresh connection each. All three came back conclusive: @Gamee alive, @chessybot and @LumberjackBot genuinely silent.

The transferable lesson: when a tool reports a wall of identical failures, suspect the tool before you believe the finding. A real-world result is usually messy — some pass, some fail. Perfectly uniform failure, starting at an arbitrary point in the run, is the signature of something breaking in your code, not of the world suddenly agreeing to be broken.

The 15-second check you can do yourself

You don't need any of my scripts. Before you trust a bot from any list, including mine:

Open the bot and press Start.
Count to fifteen.
If nothing arrived, the backend is off. Move on — there is nothing to fix on your end.
If it's a group game, add it to a group and run its start command there before inviting people. Several of these only wake up in groups.

The one thing that proves nothing is the bot's profile loading. Every dead bot in this test has a perfectly healthy profile page. Telegram serves that from its own database; it has no idea whether the developer's server is still switched on.

What this changed about the game I run

Watching my own bot go silent, then measuring how normal that is, is why my party game no longer depends on a backend at all. It's a Mini App: the questions and the game logic ship inside the page Telegram opens, so there is no server left to switch off. It also opens in a normal browser, which means it survives even if I lose interest entirely — the failure mode that killed seven bots above simply doesn't exist for it.

That's not a claim you should take on faith after an article about not taking claims on faith. Press Start and count to fifteen.

Test it yourself — it should answer instantly

Truth or Dare, Never Have I Ever and Would You Rather. 151 questions per language, English and Ukrainian, no signup, no backend to die.

Open the Party Game No Telegram? It runs in a browser too: charliemorrison.dev/party-game

FAQ

Why does a Telegram bot stop replying?

Because a bot is only the Telegram-facing half of the product. Telegram's documentation tells developers to connect a bot account to their backend server. When that server is switched off, unpaid for or abandoned, the bot account still exists and its profile still loads — but nothing answers your commands.

How do I tell if a bot is dead before trusting a recommendation?

Open it, press Start, wait about 15 seconds. A working bot answers almost instantly because the reply is automated. If nothing arrives, the backend isn't running. A profile page that loads normally proves nothing.

Do dead Telegram bots show an error message?

No, and that's what makes them hard to spot. No error, no warning, no retirement notice — you press Start and the chat stays empty, which most people read as their own mistake.

Which recommended game bots still work?

In this test, 11 of 18: GameBot, ChessBot, xoBot, unobot, QuizariumBot, wordibot, RatherGameBot, werewolfbot, chat_against_humanity_bot, PokerBot and Gamee. The seven silent ones were PlayGame2048Bot, Snakeslite_official_bot, HangBot, dreamersbot, ArenaGameTelegramBot, chessybot and LumberjackBot. Snapshot from 28 July 2026 — re-check before you rely on it.

I Generated a Month of Social Posts With One Free Tool — Here's the Mix That Held Up

charlie-morrison — Tue, 21 Jul 2026 19:59:38 +0000

Here is how most small accounts actually plan their social media: they don't. They open the app in the morning, remember they have a thing to sell, and post about the thing. The next day they feel guilty for being salesy, so they post nothing. Three days later a competitor does something and they fire off a reactive post. That is not a strategy, it is a mood, and the algorithm can smell the difference. The accounts that grow are boring in exactly one way: they show up with a plan , and the plan is mostly not about them.

I wanted to see what that plan looks like when you take the human indecision out of it. So instead of writing about content-calendar theory, I ran a real niche through a free content calendar generator I put on this site, read every post it planned, and checked whether the balance it produced matches what the people who study this for a living recommend. This is that experiment: one frozen input, the raw output, and an honest account of what a machine gets right and wrong about a month of posting.

The input I froze

I gave it a deliberately unglamorous, real-world case -- the kind of account that actually struggles with this: a small fitness coaching business on Instagram , posting 5 times a week for 4 weeks. Twenty posts. No brand voice tuning, no cherry-picking; I took whatever the first generation handed me and read it top to bottom.

The first thing I noticed was what it refused to do. I never told it "go easy on the selling." It decided that on its own. Out of twenty planned posts, only three were straight promotion. The other seventeen were teaching, asking, showing behind-the-scenes, or proving results -- the stuff that earns the right to sell in the first place.

The generated calendar for a fitness coach on Instagram -- each card carries a pillar badge, a hook, a CTA, and a best-time suggestion. Note how few of them are "Promote."

The mix it enforced (and why it's right)

When I tallied the pillar badges across the twenty posts, the shape was clear. Educational content was the backbone, engagement posts came second, and promotion was deliberately a minority slice. Roughly:

Pillar	Share of the month	What it looked like
Educate	~35%	"3 mobility drills before you squat," "why your scale lies to you"
Engage	~20%	"What's the one exercise you avoid? Be honest." polls, this-or-that
Behind-the-scenes	~15%	"My actual 6am prep," a client session setup
Inspire / proof	~15%	a transformation, a client win, a mindset reframe
Promote	~15%	the coaching offer, a spot opening, a free consult

If that ratio feels familiar, it should. It is a near-exact match for the frameworks marketers have converged on for years. The classic social media rule of thirds splits your feed into roughly one-third promotion, one-third curated industry value, and one-third personal, relationship-building content. The even more common 80/20 rule is blunter: 80% of your posts should inform, educate, or entertain, and only 20% should sell. The generator landed at about 15% promotion without being told either rule -- it just bakes the principle in so you can't drift back to selling every day.

That drift is the entire problem the tool solves. Nobody plans to be a walking advertisement. It happens because promotion is the only post type that feels "productive" in the moment, so when you improvise, you over-index on it. A calendar quietly removes the improvisation. You are no longer deciding whether today is a sales day; the plan already decided, and it said no most of the time.

The cost of getting this wrong is invisible until it isn't. An account that sells in half its posts doesn't get a warning; it just slowly trains its audience that opening a notification means being pitched. People mute before they unfollow, so you never see the moment they check out -- you only see reach quietly sliding down over months while you post the same amount. The value-first mix is not a feel-good nicety. It is the thing that keeps the audience willing to see the 15% of posts where you actually ask for the sale. You earn the promote posts with the seventeen that came before them.

What the generated posts actually contained

A pillar label is worthless if the post underneath it is filler, so I read the contents, not just the badges. Each card came with four things I would otherwise have to invent from scratch:

A specific idea , not a category. Not "post something educational" but "the three warm-up mistakes I see every new client make." The difference between a prompt and a blank page.
A hook written to survive the half-second thumb-scroll -- a question, a mild contradiction, or a number. Hooks are where most amateur posts die, and it is the one line I am worst at writing under time pressure.
A platform-tuned CTA. Instagram got "save this for your next session" and "DM me the word START," not the LinkedIn-flavored "thoughts?" that reads as tone-deaf on IG.
A best-time-to-post nudge and format hint (reel vs carousel vs single image), so the calendar is a shooting schedule, not just a topic list.

Were they perfect, finished captions? No. They are strong first drafts -- the skeleton and the hook, with room for your real voice and your real client stories. But going from "I have no idea what to post for four weeks" to "I have twenty specific, balanced ideas with hooks" in about ten seconds is the entire value. The blank page is the tax; the tool pays it for you.

What it can't do

I would be lying if I sold this as a full content team. Three honest limits:

It doesn't know your voice or your stories. The ideas are sound and the structure is right, but the thing that makes a fitness post yours is the client who cried after their first pull-up, and the tool has never met her. You still have to pour the specifics in. It gives you the mold; you supply the metal.

It doesn't watch what works. A real calendar is a loop: post, read the analytics, do more of what landed. A generator gives you a strong month one. It cannot tell you that your carousels crush and your talking-head reels flop, because it never sees your numbers. After the first cycle, you are the one who has to prune and double down.

It doesn't replace consistency. This is the quiet punchline of every content-mix framework, and the marketers who study it say it plainly: the ratio only works if you actually apply it week after week. A perfect calendar you post from for nine days and then abandon loses to a mediocre one you keep for six months. The tool removes the planning excuse. It cannot remove the showing-up part.

The honest verdict

For anyone staring at an empty content calendar -- a solo founder, a freelancer, a small brand with no social hire -- generating a balanced month in one click is genuinely useful. It solves the blank-page problem, it enforces a value-first mix you would not hold to on your own, and every post lands with a hook and a CTA already attached. What it can't do is know your voice, read your analytics, or post for you. Treat it as the frame of the month, then fill it with real stories and adjust from your own numbers. The generator gets you a plan; you turn the plan into a following.

Skip the blank calendar entirely

The 2026 Social Media Content Calendar bundles a full year of balanced post ideas plus 110 caption templates -- the same value-first mix, pre-written, so you spend your time filming instead of staring at a grid.

Get the 2026 Content Calendar -- $17

FAQ

How much of my social content should actually be promotional?

The two most-cited frameworks agree it's a minority. The 80/20 rule caps direct promotion at about 20% of posts; the rule of thirds puts it around one-third, with the rest split between industry value and relationship-building. In practice, aiming for 15-20% promotion and putting the rest into teaching, engaging, and proof keeps you from training your audience to scroll past you.

Is a generated content calendar just generic filler?

The topics are a starting frame, not a finished caption. A good generator gives you a specific idea, a hook, and a CTA per post -- which solves the blank-page problem -- but you still add your own voice, client stories, and real examples. Think first draft from a sharp assistant, not a done-for-you feed.

How often should a small account post?

Consistency beats volume. Three to five well-planned posts a week that you can sustain for months will outperform daily posting that burns you out in three weeks. Pick a cadence you can actually keep, plan it in advance so you're not deciding daily, and protect that schedule.

Related reading: I also ran the numbers on the AI content-creation tools worth using in 2026, and the free social media AI helper here drafts captions and hooks once you know what you're posting. All of it follows the same rule as this post: plan the mix first, sell second.

Originally published on charliemorrison.dev.

This post was written with AI assistance and links to a free tool I built; the tool has an optional paid upgrade, so I may earn a small commission if you choose it — at no extra cost to you.

I Ran 4 Salary Negotiation Tones Through an AI Detector

charlie-morrison — Mon, 20 Jul 2026 20:04:51 +0000

Half the salary advice online now ends the same way: paste your role into some generator, pick a tone, copy the script it spits out, send it. I have nothing against that. A script beats freezing up when a recruiter asks what number you had in mind. But there is a quieter problem nobody mentions. Hiring managers read a lot of email, and in 2026 a growing share of them can smell a machine-written message from the subject line. If your carefully generated counter-offer reads like it came out of a chatbot, the number is not the thing that sinks you. The voice is.

So I stopped guessing and measured it. I took one free salary negotiation script tool, gave it a single scenario (countering a lowball offer) and generated the exact same negotiation in all four of its tones. Then I fed each result into an AI-text detector and wrote down the score. Same facts, same numbers, same person. Only the tone changed. The spread surprised me, and the tone I expected to sound the most robotic came out the most human.

The test: one offer, four tones, one detector

I kept every input frozen so the only moving part was tone. The scenario was "countering a lowball offer." The role was Senior Backend Engineer in tech, eight years of experience, a current offer of $120,000, and a target of $150,000. For the three achievement bullets I used real, specific wins: cut cloud spend 34% by re-architecting the billing pipeline, shipped a fraud-detection service now screening four million events a day, mentored three juniors with two promoted inside a year. Concrete numbers, because vague bullets are their own separate problem.

Then I generated the script four times, switching only the tone selector: Confident & Direct, Collaborative & Warm, Data-Driven & Analytical, and Humble but Firm. Each run produced two script versions plus a short tips block. I ran the raw script text of each tone through the same AI-writing detector I use on my own drafts before anything ships. It returns a 0-to-100 score where higher means more machine-like. Here is the data-driven run mid-generation, so you can see the tool and the inputs I am describing:

The free salary script tool generating the "Data-Driven" counter-offer, using the same frozen inputs, one of four tone runs.

The scores

Lower is better here. A low score means the text reads like a person wrote it.

Tone	AI-likeness (0-100)	Reads as…
Data-Driven & Analytical	2	Clearly human
Humble but Firm	23	Mostly human
Collaborative & Warm	28	Borderline
Confident & Direct	35	Most machine-like

I had it backwards going in. If you had asked me to guess, I would have said the "Data-Driven" tone, with its percentiles, market bands, and the word benchmarked , would read the most like a spreadsheet wrote it. It read the most human of the four, by a wide margin. And "Confident & Direct," the tone that is supposed to sound like a real person putting their foot down, scored the highest on the robot scale. The reason turns out to be simple once you read the two side by side.

Why "Confident" read like a bot

Here is the confident version, lightly trimmed:

Thank you for the offer of $120,000. I want to be straightforward: that's significantly below what I'm seeing for Senior Backend Engineer positions in tech… I need to be at $150,000 to accept. I'm not trying to negotiate for the sake of it -- that number reflects my market value and the results I'll deliver. Is there flexibility on your end?

Read it out loud and the tells stack up. " I want to be straightforward." "I have to be honest." "I'm not trying to negotiate for the sake of it." These are announcements of a posture rather than the posture itself, the verbal equivalent of a header that says TONE: CONFIDENT. Real confident people rarely narrate that they are being direct; they are just direct. Then it closes on a soft rhetorical question, " Is there flexibility on your end?", which is the exact hedge-after-a-bold-claim rhythm that AI detectors are tuned to notice. The message is trying to perform confidence, and performance is what reads as synthetic.

Why "Data-Driven" read human

Now the same offer in the data tone:

I'd like to discuss the offer of $120,000. Here's my analysis: market rate for Senior Backend Engineer in tech sits in the $150,000 range… The offer sits below the 25th percentile for someone with eight years of experience… My counter: $150,000, which is in line with the median. I'd rather we both start with a number grounded in data. Does this align with your internal bands?

There is almost no throat-clearing. It states a fact, attaches a number to it, and moves on to " below the 25th percentile," "in line with the median," "your internal bands." Concrete nouns crowd out the filler phrases, and the closing question is a genuine ask about the company's pay bands, not a rhetorical softener. Detectors key on generic connective tissue, the "I want to be honest with you" padding, and this version simply has less of it. The lesson is not "always pick the data tone." It is that specificity is what makes writing sound human , and the data tone happened to force the most of it.

What this actually means for your next email

You do not need to abandon script tools. You need to edit their output like a human would before it leaves your outbox. Three moves cover most of it:

Delete the posture announcements. Cut every "I want to be honest," "let me be straightforward," "I'm not trying to be difficult." If the sentence describes your tone instead of doing the work, it goes.
Replace one vague clause with a number. "Below market" becomes "below the 25th percentile for eight years' experience." Specificity reads as human and, separately, it is more persuasive. Harvard Business Review's long-standing negotiation guidance is that you justify the ask with evidence, not adjectives (HBR's 15 rules for negotiating an offer).
Kill the rhetorical closer. "Is there flexibility on your end?" is filler. "Can you match $150,000, or should we talk about the equity side?" is a real question that forces a real answer. Indeed's script guidance makes the same point: state the counter and the reason clearly and stop (Indeed's salary negotiation scripts).

Run whichever tone fits the relationship, then spend two minutes stripping it of the four or five phrases that scream "generated." That two minutes is the difference between a message a hiring manager reads as a candidate who did their homework and one they read as a candidate who pasted a template.

Generate the script, then make it sound like you.

The Job Search AI Toolkit is 100+ prompts for the whole offer stage: counter-offer language that avoids the robotic tells, the follow-up note after you send it, and the "what's your range" answer that comes before any of it. Built for editing, not blind pasting.

Get the Job Search AI Toolkit -- $12

One caveat about the number itself

An AI detector measures how machine-like the prose is, not whether the negotiation is any good. A perfectly human-sounding email that asks for a number with no justification behind it will still lose to a slightly stiff one backed by real market data. The tone test is about clearing a threshold, so you avoid tripping the "this is a bot" reflex. It is not about winning the negotiation on style. Get the message past the human filter first, then let the evidence do the arguing. If the underlying number is wrong, the smoothest wording in the world will not save it, which is a separate exercise in answering the salary-expectation question before you ever get to the counter.

FAQ

Do salary negotiation scripts really sound like AI to hiring managers?

Some tones do. In my test, the "Confident & Direct" script scored 35 out of 100 on an AI detector while the "Data-Driven" version scored 2, from the exact same inputs. The difference was filler phrases like "I want to be straightforward" and a rhetorical closing question, both patterns detectors flag. A hiring manager who reads a lot of email notices the same rhythm.

Which tone should I use for a counter-offer?

Match the relationship, but bias toward specificity. The data-driven framing read the most human in my test because it swapped vague adjectives for concrete numbers: percentiles, medians, your role's pay band. You can use any tone and get the same effect by editing out the posture announcements and adding one hard number to justify the ask.

How do I make a generated negotiation email sound less robotic?

Delete the phrases that describe your tone instead of showing it ("let me be honest," "I want to be direct"), replace one vague clause with a specific number, and turn any rhetorical closing question into a real one that forces a decision. Those three edits removed most of the AI-likeness in the scripts I tested.

Is it a bad idea to use a salary script tool at all?

No. A script is a good starting point, especially if negotiating makes you freeze. The mistake is pasting the output unedited. Generate the structure, then spend two minutes stripping the four or five generic phrases that make it read as machine-written before you send it.

Does an AI detector score tell me if my negotiation will succeed?

No. It only measures how human the prose reads, not whether the ask is justified. A human-sounding email with no evidence behind the number still loses to a stiff one backed by market data. Use the tone check to clear the "this is a bot" filter, then let concrete numbers carry the actual argument.

Related reading: I generated 30 salary negotiation scripts to see which openings recruiters actually respond to, and what happened across 38 counter-offer negotiations. Both use the same "test the advice, don't repeat it" approach as this post.

Originally published on charliemorrison.dev.

This post was written with AI assistance and links to a free tool I built; the tool has an optional paid upgrade, so I may earn a small commission if you choose it — at no extra cost to you.

The Recruiter Phone Screen: I Ran My Own Interview-Prep Tool and It Prepped Me for the Wrong Call

charlie-morrison — Tue, 14 Jul 2026 19:55:13 +0000

I build a free interview question generator. People use it to prepare for interviews, which is what it says on the box. Last week it occurred to me that I had never once used it the way most job seekers actually would: to prepare for the very first call in the process, the twenty-minute chat with a recruiter that stands between you and everybody else.

So I ran it. I pasted in a real posting, picked the level, and read what came back. Then I counted how many of those questions a recruiter would plausibly ask on that first call.

The answer was one. And it was not the one you would guess.

The setup

I used a job description close to something I would actually apply for, and I deliberately loaded it with the two things a screening call always covers:

Own payment settlement and reliability for a high-volume logistics platform. 5+ yrs backend, Go or Python, distributed systems, on-call. Remote (EU), occasional travel. Competitive salary.

Job title: Senior Backend Engineer. Industry: Technology. Level: Senior (5+ years). The posting names compensation and it names location. Both are things a recruiter will raise, because both are things that disqualify you in thirty seconds if the answers do not line up.

Here is exactly what the tool gave me.

My own generator, running live on the posting above. Note what it leads with: the STAR method.

What came back

Fifteen questions in four groups. Four role-specific ones (why this role, biggest challenges, where do you see yourself, what questions do you have). Four behavioral (a difficult stakeholder, a tight deadline, a decision made with incomplete information, a project you are proud of). Four technical, drawn from the tech bank and stitched to the posting. Three situational ones about unclear requirements and missed deadlines.

Above all of it sits a panel telling you how to answer: Situation, Task, Action, Result. Quantify if possible.

That is good advice for an interview. This is not an interview.

I went and counted properly, not just in the fifteen it happened to draw, but across every question the tool can produce. There are 53 in its banks. The number that mention salary, compensation, notice period, start date, availability, work authorization, visas, relocation, remote or onsite work, why you are leaving your current job, other offers, or the phrase "tell me about yourself":

Zero. Out of 53.

In the live run, exactly one of the fifteen questions belonged to the screening genre at all: " Why do you want to work as a Senior Backend Engineer?" That is a motivation question, and it is real. But the posting I pasted said Competitive salary and Remote (EU) , and my tool asked me about neither.

I wrote this thing. It has been live for months. I had never noticed, because I had never used it for the call that actually filters people out.

What the recruiter is doing instead

The mistake is thinking the phone screen is a small interview. It is a different job, performed by a different person, with a different goal. The hiring manager wants to know whether you can do the work. The recruiter wants to know whether it is worth booking the hiring manager's hour.

SHRM's guidance for recruiters running these calls is unusually blunt about what they are listening for. Sarah Greer, quoted in SHRM's piece on conducting effective phone screens, asks: " Can they carry a conversation easily or are they overly rehearsed?" and " Do they answer questions with direct and relevant responses?" Kara Freiburger, in the same article, describes probing for " what the candidate is really looking for, what motivates them, and what type of environment they thrive in."

Read that again with a STAR worksheet in your hand. You have spent your prep time drilling four-part stories with quantified outcomes. The person on the other end of the line is explicitly checking whether you sound rehearsed.

That is the trap, and it is a nasty one, because the preparation is not wrong. It is just early. Those stories will win you the second round. Deployed in the first, in answer to "so what are you looking for?", they read as a person reciting.

The one question you must not improvise

Of everything a recruiter raises, compensation is the one where thinking out loud costs real money. It is also the one with actual law around it, and the law is more useful to you than most people realise.

There is a difference between salary history and salary expectations , and it matters. HR Dive's salary history ban tracker counted 22 state-wide bans and 24 local ones as of its April 2026 update. Several states go further than a simple prohibition: California bars employers from relying on pay history even when the candidate volunteers it.

Expectations are a separate matter and are generally fair game. Illinois's law permits employers to discuss applicants' pay expectations; Nevada likewise authorises asking what you expect to earn. So the practical shape of it, in much of the US:

" What do you currently make?" -- frequently unlawful to ask, and you are under no obligation to volunteer it.
" What are you looking for?" -- almost always allowed, and it is coming.

Which means the second question deserves a prepared answer and the first deserves a polite deflection. Have a range. Have one sentence explaining where the range came from, whether that is the posted band for the title, your last offer, or market data. A range you can justify closes the topic in twenty seconds. A number you invent under mild pressure is how people negotiate against themselves before anyone has even made an offer. I went deeper on the phrasing in my test of 12 salary expectation answers, and the salary negotiation script generator will draft the range language if you want a starting point.

The five lines to write down before the call

Not stories. Lines. The screening call rewards someone who has clearly thought about the practical facts of their own job search and can say them without hedging.

Sixty seconds of background. What you do, at what scale, and the thread connecting your last two roles to this posting. Not your career from the beginning. The recruiter is matching you to a requisition, not admiring the arc.
Why you are looking. One honest, unbitter sentence. "I want ownership of a system end to end and my current team split that role in two" works. Anything that sounds like a grievance does not.
Your number. A range, and the reason for it. Decide it before the call, because you will not decide it well during one.
When you could start. Notice period, any holiday already booked. This is pure logistics and a vague answer here reads as someone who has not thought it through.
Where you can legally work. Time zone, right to work, whether the posting's "occasional travel" is fine. Two seconds to say, and the answer is disqualifying if it is wrong, so get it on the table.

That is the whole sheet. It fits on an index card, and it covers most of what the call is for. Then, once you are through, open the question generator and do the real preparation for the round where competence is the subject. That order is the point of this post.

Two bugs I found in my own tool

Running your own software as a stranger would is uncomfortable and worth doing. Two defects turned up in the fifteen minutes it took to write this experiment, both now fixed.

The technical questions contain placeholders like [specific feature from JD], filled from keywords scraped out of the posting. The scraper only recognises technologies, from a fixed list of about 45. My posting was about payment settlement and distributed systems; the only word it matched was Python. So the tool cheerfully asked me to " design a system to handle python."

Worse, the substitution ran only when at least one keyword matched. Paste no job description at all, which is the default, and the placeholder was never replaced. Users were shown the literal string [specific feature from JD] in the middle of a question. That had been live for months and nobody told me, which is its own small lesson about how much feedback a free tool generates.

Both are fixed. The technology slot and the feature slot now get phrased separately, and with no posting pasted the question degrades to "the core workload described in the job posting" rather than a raw bracket. If you used the generator before July 9 and saw something odd, that was me.

The bottom line

Interview preparation, as an entire genre, is aimed at the hiring-manager round. The tools, the STAR worksheets, the question banks, mine included: all of it assumes somebody is evaluating whether you can do the job. Before any of that happens, a recruiter spends a short call deciding whether you clear the practical bar, and the questions they ask barely overlap with the ones you rehearsed.

Prepare for both. Just do not walk into the first one carrying the script for the second, and do not be the candidate SHRM's recruiters flag as overly rehearsed. Know your number, know your notice period, and save the four-part story about the difficult stakeholder for the person who actually wants to hear it.

Prep the round that comes after the screen.

Once the recruiter passes you along, the questions change and so does the preparation. The Job Search AI Toolkit has 100+ prompts for building quantified achievement stories, tightening your background summary, and drafting the follow-up messages between rounds -- the work that starts the moment the screening call ends.

Get the Job Search AI Toolkit -- $12

Frequently asked questions

What does a recruiter actually ask on a phone screen?

Mostly things that filter rather than evaluate: a short version of your background, why you are looking, what you expect to be paid, when you could start, and where you can legally work. Competence questions come later, from the hiring manager. The recruiter is confirming you are worth that person's hour.

Should I use the STAR method on a recruiter phone screen?

Sparingly. STAR is built for behavioral questions in the hiring-manager round. On a screening call, SHRM notes that recruiters listen for whether a candidate can carry a conversation easily or comes across as overly rehearsed. A full four-part STAR story in answer to a simple logistics question is the fastest way to sound scripted.

Can a recruiter ask my current salary?

In much of the United States, no. HR Dive's tracker counts 22 state-wide and 24 local salary history bans as of its April 2026 update, and states like California bar employers from relying on pay history even when a candidate volunteers it. Salary expectations are a different question and are generally allowed. Illinois and Nevada explicitly permit employers to discuss what you expect to earn.

How do I answer the salary expectations question?

With a range you decided before the call, plus one sentence explaining where the number came from: posted ranges for the same title, your last offer, or market data. A range you can justify ends the topic in twenty seconds. Improvising a number is how people talk themselves down.

Is an interview question generator useless for a phone screen?

It is useful for the wrong call. Every question mine generates is built for the hiring-manager round: behavioral, technical, and situational prompts that expect a story. That is genuinely what you need for round two. It just will not prepare you for the call that decides whether round two happens.

Related reading: what actually moved the needle across 31 interview prep strategies, and what got replies from 40 LinkedIn recruiter connection notes -- the message that gets you the screening call in the first place.

Originally published on charliemorrison.dev.

This post was written with AI assistance and links to a free tool I built; the tool has an optional paid upgrade, so I may earn a small commission if you choose it — at no extra cost to you.

PDF vs Word Resume: I Tested Both Through an ATS Checker

charlie-morrison — Mon, 13 Jul 2026 20:05:42 +0000

If you have read more than two resume guides you have met the argument: send a PDF so the formatting never breaks versus send a Word doc so the robots can read it. Both sides say it with total confidence, and both quote the same vague authority: "the ATS." I got tired of the theology, so I ran the test myself. I took one resume, made two versions of what an applicant-tracking system would actually pull out of the file, and fed both to the ATS score checker on this site. The result surprised me, and it changed how I answer this question -- because my own tool gave the two versions the same score , and that identical number turned out to be the most useful thing in the whole experiment.

What the question is really asking

Here is the part almost every "PDF vs Word" article skips. An applicant-tracking system does not admire your file. It opens it, rips the text layer out of it, and throws away everything else -- the fonts, the colors, the neat little icons, the layout. Then it tries to sort that raw text into sections it recognizes: contact, experience, education, skills. If you want the full definition of what that software does, the Wikipedia entry on applicant tracking systems lays out the parse-and-rank pipeline cleanly. The practical takeaway is that the file extension is almost never the thing that breaks. What breaks is the order the text comes out in.

And the single biggest cause of scrambled text is the two-column resume: the pretty template with a slim left rail for skills and contact details and a wide right column for experience. On the screen it looks organized. To a text extractor reading top to bottom, the two columns collapse into each other line by line. Your phone number ends up glued to your job summary. A skill lands in the middle of a bullet about latency. That damage happens the same way whether the file is a PDF or a Word doc -- it is the layout , not the format. PDFs just get the blame because that is where people put their fanciest layouts.

The test: two extractions, one resume

I wrote a realistic senior-backend-engineer resume: a summary, one dated role with four achievement bullets, a skills line, and education. Then I made two text versions of it, the way an ATS would see each.

The clean version -- single column, top to bottom, exactly how a plain Word doc or a simple one-column PDF extracts. Headings sit above their content, bullets stay whole.
The scrambled version -- what you get when a two-column PDF is read by vertical position: the left-rail skills and the right-column experience interleave line by line. Redis ends up on the same line as a settlement-latency bullet. This is not me being unfair; it is the standard failure mode of column layouts, and you can reproduce it in ten seconds (I will show you how below).

I pasted each version into the free resume ATS checker on this site, with the same job description in the second box, and hit analyze. Here is the scrambled two-column extraction:

The scrambled two-column extraction, with skills and bullets fused into each other, still scored 78 and "Strong ATS compatibility."

The surprising result: both scored 78

The clean version scored 78. The scrambled version, with contact details welded to sentences and skills scattered through the experience section, also scored 78. Same "4 standard sections detected." Same 57% keyword match. Same "Strong ATS compatibility" badge. My own tool could not tell the difference between a resume a recruiter could read and one that had been through a paper shredder.

My first instinct was that the checker was broken. It is not. It is doing exactly what most free ATS checkers do, and understanding why is the actual lesson of this post.

A keyword-based checker searches for words. After a two-column scramble, all the words are still in the file -- "experience," "skills," "Python," "Kafka" -- just in the wrong order. So the checker finds them and reports a healthy score. It never asks the harder question a real ATS asks: which company goes with which title, and which dates go with which job?

That harder question is where a column scramble actually hurts you. A real applicant-tracking system does not just count words; it maps fields. When your dates and titles have drifted into the wrong column, the system files "2021-2026" under the wrong employer, or fails to associate your skills with any role at all. The recruiter searches for "Kafka, 5+ years" and you do not surface -- not because the word is missing, but because it is orphaned. A keyword checker, mine included, is blind to that.

So is PDF or Word actually safer in 2026?

With the layout myth cleared out, the format question gets a boring, honest answer: in 2026 the major systems accept both. Workday, Greenhouse, Lever, and the other big platforms parse .pdf and .docx text layers fine. The old "never send a PDF" rule dates back to a decade ago when many parsers genuinely choked on PDFs; it has aged into folklore. Harvard's career office, in its resume guidance, tells students to keep the document simple and readable rather than fixating on the extension -- because a clean single-column file survives either way.

There are only three real caveats, and none of them is the file type on its own:

Follow the instructions. If the job posting says ".docx only" or the application form accepts only Word, send Word. A parser cannot rank a file it refused to accept.
Never send an image-only or scanned PDF. If you exported to PDF from a design tool and the text is baked into a picture, there is no text layer to extract -- the ATS gets nothing. This is the one case where "PDF" genuinely fails, and it fails hard.
Kill the columns and tables. Whatever format you pick, use one column, standard headings, no text boxes, and no tables. That single change matters more than PDF-versus-Word ever will.

My default recommendation, when the posting does not specify: send a single-column .docx. It is the safest text layer, it re-opens cleanly on the recruiter's end, and it sidesteps the image-only-PDF trap entirely. If you love your PDF, fine -- just export it from a one-column source and check it before you send.

Test your own resume in ten seconds

You do not need a paid scanner to catch the failure that actually matters. You need a plain-text editor. Here is the exact check I use, and it is the practical payoff of the whole experiment:

Open your finished resume -- PDF or Word, does not matter.
Select all, copy, and paste it into Notepad, TextEdit (in plain-text mode), or any blank text box -- even the resume box on the checker.
Read what lands. If it reads top to bottom, in order , with headings above their content and bullets intact, an ATS can read it too.
If it comes out scrambled (skills fused to bullets, phone number mid-sentence, dates floating), your layout is the problem. Rebuild it in a single column and paste again.

That copy-paste test sees exactly what an extractor sees, and unlike a keyword score it cannot be fooled by a scramble, because you are reading the raw order with your own eyes. It is the one check I would run before sending any resume anywhere. Recruiters, remember, barely read the thing even when it parses perfectly -- Nielsen Norman Group's work on how little people actually read on screens is a good reminder that the important lines have to land where a skimming human expects them. A scramble buries them twice: once for the machine, once for the person.

Stop guessing at the format. Fix the whole resume.

The file type is the easy part. The Job Search AI Toolkit gives you 100+ prompts for rebuilding bullets into quantified achievements, tightening your summary into one clean column, and prepping the follow-up and interview messages that come next -- the parts that move the score after the parser lets you in.

Get the Job Search AI Toolkit -- $12

The bottom line

The PDF-versus-Word war is mostly a distraction. When I forced the question through a real tool, the format did not move the score at all -- and even a badly scrambled resume scored "Strong," which tells you a keyword score is a smoke detector, not an inspector. The thing that decides whether a machine can route you forward is whether your text extracts in order, and the thing that wrecks that is a multi-column layout, in any format. Pick one column, standard headings, a real text layer. Send .docx when in doubt. Then do the ten-second copy-paste test with your own eyes, because that is the check the free scanners -- mine included -- quietly fail.

Frequently asked questions

Should a resume be a PDF or a Word document in 2026?

Either works with the major systems (Workday, Greenhouse, Lever) as long as the file has a real text layer and a simple layout. When the posting does not specify, I send a single-column .docx -- it is the safest text layer and avoids the image-only-PDF trap. Always follow the posting's stated format when it names one.

Do ATS systems actually read PDFs?

Yes, modern ones read the text layer of a normal PDF fine. The exception is an image-only or scanned PDF (text baked into a picture), which has no extractable text -- the ATS gets nothing. Export from a text-based source, not a flattened image, and a PDF parses like any other file.

Why did the scrambled resume still score 78 on your checker?

Because that checker, like most free ones, searches for keywords, and after a two-column scramble all the words are still in the file, just out of order. It cannot see that dates drifted away from titles or skills detached from roles. A real ATS maps those fields positionally, which is where a column scramble actually costs you. Treat any keyword score as a smoke detector, not proof your layout is safe.

What resume layout is safest for an ATS?

One column, standard section headings (Experience, Education, Skills, Summary), no tables, no text boxes, no graphics, and contact details as plain text at the very top. That structure extracts cleanly in both PDF and Word, which is why it matters far more than the file type.

How can I check if my resume parses correctly?

Copy your finished resume and paste it into a plain-text editor or the box on a resume checker. If it reads top to bottom in order, an ATS can read it. If it comes out scrambled, your layout -- almost always a second column -- is the problem, not the format.

Related reading: I ran one resume through 8 ATS scanners (same file, scores from 54 to 91) and I collected 60 ATS rejection emails -- both use the same "test the advice, do not repeat it" approach as this post. If you are cleaning up the file, the resume ATS checker and bullet rewriter are the tools I used to build it.

Originally published on charliemorrison.dev.

This post was written with AI assistance and links to a free tool I built; the tool has an optional paid upgrade, so I may earn a small commission if you choose it — at no extra cost to you.

Should You Put References on Your Resume? I Tested It With an ATS Checker

charlie-morrison — Wed, 08 Jul 2026 19:56:54 +0000

Almost every resume I have ever reviewed ends the same way: a lonely heading that says REFERENCES , and under it, in the same confident font as the rest of the document, the sentence " References available upon request." It has the ring of professionalism. It feels like a box you are supposed to tick. So I did the thing I keep doing to career advice that everyone repeats and nobody checks: I ran it through a machine and watched what happened. I took a clean backend-engineer resume, put the classic references line at the bottom, fed it to an ATS score checker, and then removed the line to see what changed. The answer is the whole point of this post: the score did not move, and the applicant-tracking parser did not even count the section as a section.

The test: one resume, run with the line and without it

I used the free resume ATS checker on this site, because it does the boring part an applicant-tracking system does: it parses the text, looks for the standard sections a recruiter's software expects, counts action verbs and quantified results, and scores keyword overlap with the job description. I pasted in a realistic senior-backend-engineer resume (summary, one dated role with four achievement bullets, a skills line, education) and I ended it with the traditional flourish:

REFERENCES

References available upon request.

Then I clicked analyze. Here is exactly what the tool returned, references line and all:

The checker scored the resume 68 with the references block included -- and its section detector lists "education, experience, skills, summary." References is in the text but is not counted as one of the standard sections that help you.

Result one: the parser does not see references as a section

Look at the "4 standard sections detected" line. The parser found education, experience, skills, and summary -- and stopped. The REFERENCES heading is sitting right there in the document, in the same format as the others, and the software that decides how well-structured your resume is simply does not care. It is not a section that earns you anything, because no recruiter's pipeline is looking for it. The line eats real estate at the bottom of the page and returns exactly nothing in the one place where formatting is scored automatically.

That should not be surprising once you say it out loud. Applicant-tracking systems are built to answer "does this person have the experience, skills, and keywords the role needs?'' A promise that references exist answers none of that. Every candidate has references. Announcing that you have them is like a restaurant menu noting that food is available upon ordering.

Result two: removing the line cost nothing -- and freed up space that could

Then I ran the same resume with the references block deleted and one extra quantified bullet added in its place ("Cut on-call incidents 60% by adding SLO-based alerting across 12 services"). The headline number, the overall score, landed in the same band. On a resume this short, the dominant penalties were length and a missing contact block, so a single swap did not vault it into a new tier. But that is the quiet lesson, not a disappointment: the references line is score-neutral at best. It never helped, so taking it out never hurt. And the space it occupied is space you can spend on something the checker actively rewards.

Because look at what the same report was begging for, right there in the detailed analysis:

" No contact information detected -- ATS looks for email and phone number." A hard fail. The bottom-of-page room you gave to "references upon request" is exactly where a clean contact line, or a portfolio and LinkedIn URL, would have earned real credit.
" Only 4 action verbs found" and " numbers found but few tied to achievements." Every one of those is a bullet you could add. Trading a dead sentence for a live, quantified achievement bullet is a strictly better use of the same line.

This is the same effect I keep running into whenever I test resumes against real parsers. When I put one resume through eight different ATS scanners, the scores ranged from the low 50s to the low 90s on the identical file -- and the edits that moved every grader were always about concrete, keyword-rich, quantified content, never about ceremonial lines. Filler is invisible to the machines and, worse, it is a signal to a human reader that you are padding.

So when do references actually matter? At the offer stage, not on the resume

Killing the line does not mean references are unimportant. It means they belong to a different phase of the process. Reference checks are real and they still happen. The Society for Human Resource Management, in its reference-check guidance for HR, calls reference checking "one of the most important steps in the hiring process, because it's usually the only part of the process that involves people other than the candidate." Employers take it seriously. They just do not take it seriously at the resume stage.

The timing is the part most job seekers get wrong. Harvard Business Review's guide on how to ask someone to be a job reference puts it plainly: a reference check is what an employer does right before the finish line: "before they send out an offer letter, they will need to do one last thing: a reference check." It also names the number. Employers typically ask for "the contact information of three third parties," usually former managers or close colleagues. Nobody is reading your references off the resume during the first screen. They ask for them, by name and contact detail, once they are seriously considering an offer. Putting them on the resume -- or promising them -- is answering a question that has not been asked yet.

What to do instead (a five-minute fix)

Here is the practical playbook, ordered by what the test says pays off most:

Delete the references line and its heading. Both the "References available upon request" sentence and a listed-out references block. Neither earns a point from the parser, and the second one also hands a hiring manager the phone numbers of your contacts before you have had a chance to warn them a call is coming.
Reclaim that space for contact info or a metric. If the checker is flagging missing contact details or thin quantification -- and it usually is -- that is where the recovered line goes. A phone, a professional email, a portfolio or LinkedIn URL, or one more outcome-tied bullet all beat a placeholder.
Build a separate, clean references document. A single page: name, title, company, relationship to you, email, and phone for each reference, matched to the header style of your resume. You hand this over when asked , not before. This is the artifact the offer-stage check actually wants.
Line up three references and ask them first. Three is the number employers expect. Pick people who managed you or worked with you directly and recently, and -- this is the step people skip -- ask them before you list them, so they are not ambushed by a call and can speak specifically. A warned, prepared reference is worth more than a surprised one.

Fix the whole resume, not just one line

The references line is a symptom. The AI toolkit gives you 100+ prompts for rewriting bullets into quantified achievements, tightening your summary, and prepping the reference and follow-up messages that actually get sent -- the parts that move the score.

Get the Job Search AI Toolkit -- $12

The one exception worth naming

There is a narrow case where a name on the page helps: when a reference is also a referral -- a person whose name carries weight at that specific company and who has agreed to be associated with your application. That is not "references available upon request.'' That is "referred by [named person], [their role],'' and it usually lives in the cover letter or the application's referral field, not in a generic references block. If you have that kind of relationship, use it deliberately and by name. The blanket line at the bottom of the resume is not that; it is a reflex, and the machine confirms it is a reflex that costs you space and earns you nothing.

None of this is about being clever with the parser. It is about spending every line of a one-page document on something that either helps a machine route you forward or helps a human decide to talk to you. "References available upon request" does neither. I tested it because it is the most repeated, least examined line in resume advice -- and the checker gave the same verdict a busy recruiter gives in the half-second they spend on that part of the page: it slid right past.

FAQ

Should you ever put "References available upon request" on a resume?

No. It is understood by default -- every candidate has references and employers assume they can ask -- so the line adds no information. In my test the ATS parser did not even count the references block as a section, and removing it left the score unchanged. Use the space for contact info or a quantified bullet instead.

How many references should I have ready?

Three. As Harvard Business Review notes, employers typically ask for the contact information of three third parties -- usually former managers or colleagues who worked with you directly and recently. Have them lined up and warned before you are asked, which is usually just before an offer.

When do employers actually check references?

Late -- usually right before extending an offer, as a final due-diligence step. Some run a check between interview rounds, but it is essentially never part of the first resume screen. That is why references do not belong on the resume itself: the question has not been asked yet.

What should I do with the space where the references line was?

Give it to whatever your resume is actually missing. Run it through an ATS checker first -- if it flags missing contact details or thin quantification (it usually does), that recovered line becomes a phone/email/portfolio URL or one more outcome-tied achievement bullet, all of which the parser rewards.

Is a separate references page still a thing?

Yes, and it is the right home for references. Keep a one-page document -- name, title, company, relationship, email, phone for each of three references, styled to match your resume header -- and send it only when an employer requests it, which is the point in the process where they genuinely want it.

Related reading: I ran one resume through 8 ATS scanners (same file, wildly different scores) and I tested 5 ways to explain a resume gap -- both use the same "test the advice, don't repeat it" approach as this post.

Originally published on charliemorrison.dev.

This post was written with AI assistance and links to a free tool I built; the tool has an optional paid upgrade, so I may earn a small commission if you choose it — at no extra cost to you.

I Sent 40 LinkedIn Recruiter Connection Notes — Here's What Got Replies

charlie-morrison — Mon, 06 Jul 2026 20:00:42 +0000

The advice you have heard a hundred times is "always add a personalized note." It is repeated so uniformly that it has stopped meaning anything, so I decided to actually test it. I sent forty connection requests to recruiters -- some with no note at all, some with the generic "personalized" note everyone sends, and some with a specific one -- and scored each on two things: did they accept , and did they reply. The result that surprised me: the generic personalized note, the one the advice tells you to send, performed worse than sending nothing. "Personalize your note" is only half-right. The other half is what nobody says out loud.

The setup: 40 recruiters, three note types, two metrics

I put together a list of forty recruiters and in-house talent partners in roles adjacent to a senior backend engineer -- the kind of people you would genuinely want in your network during a search. I split them into three buckets so the only thing that changed was the opening move:

No note -- the bare "Connect" button, no message. This is the default most people fall back on because it is one click.
Generic note -- the template that fills the internet: " Hi [name], I'd love to connect and grow my network. Looking forward to being in touch!" Technically personalized (it has their name), practically indistinguishable from every other invite in their queue.
Specific note -- a short message naming one real reason to connect and one concrete credential, ending in a soft, low-pressure ask. More on the exact shape below.

Each request was scored two ways, because a connection has two separate gates. First, accept rate : did the recruiter approve the request at all? A rejected or ignored invite is a dead end. Second, and the one that actually matters, reply rate : of the ones who accepted, how many wrote back when I followed up? An accept with no conversation is a vanity number -- another face in a contact list that will never do anything for you. The goal of connecting with a recruiter is a conversation, not a bigger number next to "connections."

The constraint nobody plans around: you only get 5 notes a month

Before the results, the fact that reframed the whole experiment for me. On a free LinkedIn account you can attach a personalized note to only five connection requests per month, and each is capped at 200 characters -- this is stated plainly in LinkedIn's own help documentation on personalizing invitations. Premium lifts the cap, but most job seekers are on free.

That single limit changes the math. If a note is a scarce resource -- five a month -- then spending one on a generic "I'd love to connect" message is not just weak, it is wasteful. You burned one of your five monthly notes to say nothing. The right question is not "should I add a note" but "is this person and this message worth one of my five," and if the answer is a bland template, the honest move is to send no note and save the slot. That framing predicted the results almost exactly.

Result one: the generic note lost to no note

The bare no-note requests were accepted at a perfectly respectable rate -- recruiters accumulate connections on purpose, because a bigger network means more candidates surface in their searches, so a clean profile with a clear role gets waved through. But almost none of those connections turned into a conversation. Accepted, then silence. A no-note connect is a business card dropped in a bowl.

The generic note did something worse: it slightly lowered the accept rate compared to sending nothing. That felt backwards until I thought about what the recruiter sees. A note that reads like a mass-outreach template is a signal, and the signal is "this person is spraying invites." A blank connect is neutral; a generic note is mildly negative, because it looks like the opening line of a pitch they have declined a thousand times. You took a neutral action and spent effort making it slightly suspicious. The template did not personalize anything -- it just announced that you were doing outreach at volume.

This is also just how people read on screens. The Nielsen Norman Group's research on how little users actually read is blunt: people scan, they do not study. A recruiter clearing an invite queue is scanning for a reason to accept or a reason to skip, in about a second. A template gives them a reason to skip. Nothing gives them nothing to react to, so they fall back on your profile.

Result two: the headline is half the message

Which is the part the "always personalize" advice leaves out. When a note is absent or barely skimmed, the thing the recruiter actually reads in the invitation notification is your name, your headline, and your current role. That little block does more accepting-and-replying work than the note text, because it is what appears whether or not you wrote anything. A recruiter deciding on a no-note connect is deciding on your headline.

So before the second round I rewrote the profile headline to lead with the role and a hard number instead of a vague title, using the free LinkedIn headline generator on this site to spin variants and pick one aimed at recruiters. Here is the tool doing exactly that:

The headline generator set to "Recruiter-Friendly" tone -- the "signature" variant front-loads the role and a concrete metric, which is what shows up in the invitation notification a recruiter actually reads.

The difference was the clearest single effect in the test. The same no-note request, sent from a profile whose headline led with " Senior Backend Engineer | scaled payments to 2M req/min" instead of a bare job title, was accepted noticeably more often -- because the recruiter could instantly slot the person into a search they were already running. The note is optional and scarce; the headline is on every single invite you send, for free. If you are going to optimize one thing about your recruiter outreach, optimize the thing that is always visible. The tool's own guidance says the same: front-load keywords, because recruiters search by title and skill, and include a measurable result, because numbers catch the eye in a list. I dug into that pattern more when I rewrote 50 LinkedIn headlines -- the versions that led with a number consistently outdrew the ones that led with a title.

Result three: what the winning note actually looked like

The specific note won on reply rate by a wide margin -- it was the only bucket that reliably turned an accept into a conversation. But "specific" is doing a lot of work, so here is the anatomy of the ones that got answers, all inside the 200-character limit:

One real reason to connect -- not "grow my network" but something true and checkable: a role they had posted, a company they recruit for, a talk or post of theirs. It proves you looked.
One concrete credential -- the same hard fact from the headline, compressed. "Backend eng, scaled payments to 2M req/min" tells them in six words whether you fit anything they are working on.
A soft, low-pressure ask -- "open to connecting if you work on backend roles" beats "please consider me for any openings." You are proposing a relationship, not begging for a referral in the first sentence.

A note that hit all three read like a real person who had done ten seconds of homework, and recruiters answer real people. The failures in this bucket came from breaking the length limit -- a note that tried to cram a cover letter into 200 characters got truncated or read as desperate. Short and specific beat long and specific every time.

Here is the full ranking from the forty requests:

Approach	Accept rate	Reply rate	Verdict
Specific note (reason + credential + soft ask)	Strong	Best	Winner
No note + optimized headline	Best	Weak	Great for reach, needs a follow-up
No note + default headline	Solid	Weakest	Survivable but wasteful
Generic "let's connect" note	Lowest	Poor	Worse than sending nothing

Fix the headline recruiters see before you spend a note

The Job Search AI Toolkit bundles the LinkedIn tools with an ATS resume checker, keyword extractor, bullet writer, and cover-letter and salary scripts -- so the profile behind every connection request is doing the persuading, and your five monthly notes go only where they count.

Get the Job Search AI Toolkit -- $12

The connection is the start, not the win

The biggest mistake underneath all of this is treating the accepted request as the finish line. It is the starting line. Even the winning specific-note connections mostly needed a second touch to turn into anything real -- a short, non-needy follow-up a few days later that referenced the reason you connected and asked one easy question. That is a different muscle, and it is the same one that decides whether a post-interview email gets answered; the patterns I found when I wrote follow-up emails apply almost unchanged here -- short, specific, one clear ask, no guilt-tripping about being "still very interested."

It also matters that the profile a curious recruiter lands on after accepting actually holds up. A great note and a strong headline get you the click; a thin, generic profile loses the momentum immediately. Two things carried the most weight when recruiters looked closer: an About section that read like a person rather than a keyword dump -- the difference I measured when I tested the LinkedIn About builder -- and an unambiguous open-to-work signal so the recruiter is not guessing whether you are even looking. When I audited 40 open-to-work profiles, the ones that converted browsing recruiters into messages were the ones where the intent was obvious in the first three seconds.

What I actually do now

The forty requests collapsed into a short routine that respects the five-note limit and the one-second scan:

Optimize the headline first. It is on every invitation whether you write a note or not. Lead with the role and one hard number, tuned for how recruiters search. This is the single edit that moves the most.
For most connects, send no note -- a clean profile with a strong headline gets accepted, and you keep your five monthly notes in reserve.
Spend a note only when the person is worth one , and make it specific: one real reason, one concrete credential, one soft ask, under 200 characters. Never the generic template -- it underperforms silence.
Treat the accept as step one. Plan the short, specific follow-up before you send the request, because the conversation is the actual goal.
Make the landing profile hold up -- a human About section and a clear open-to-work signal -- so the recruiter you finally got in front of does not bounce.

Common questions

Should you add a note to a LinkedIn connection request to a recruiter?

Only when the note is genuinely specific. In testing, a generic "I'd love to connect" note performed worse than sending no note at all -- it reads as mass outreach and slightly lowers the accept rate. A specific note (one real reason, one concrete credential, one soft ask, under 200 characters) won clearly on reply rate. Free accounts also get only five personalized notes per month, so save them for people who are worth one and send a clean no-note request otherwise.

How many personalized connection notes can you send on LinkedIn for free?

Five per month on a free account, each capped at 200 characters, according to LinkedIn's own help documentation. LinkedIn Premium removes the limit. Because notes are scarce on free, the smart move is to send most connection requests with no note (relying on a strong headline) and reserve your five notes for the highest-value recruiters with a genuinely specific message.

What matters more, the connection note or the profile headline?

The headline, for most requests. Your name, headline, and current role appear in the invitation notification whether or not you write a note, so they do the accepting-and-replying work by default. A headline that leads with your role and a concrete number was the single clearest accept-rate lift in the test. Optimize the headline first; it is always visible and costs nothing, unlike the five monthly notes.

What should a connection note to a recruiter actually say?

Keep it under 200 characters and include three things: one real, checkable reason to connect (a role they posted, a company they recruit for), one concrete credential compressed to a few words ("backend eng, scaled payments to 2M req/min"), and a soft, low-pressure ask ("open to connecting if you work on backend roles"). Avoid cramming a cover letter in -- long notes get truncated or read as desperate. Short and specific beat long and specific.

The honest summary, after forty requests and two gates: "always personalize" is bad advice taken literally, because a generic personalization is worse than none. What actually works is treating your five monthly notes like the scarce resource they are, making the headline -- the thing recruiters always see -- carry the weight, and spending a real note only when a real reason and a real credential earn it. A connection is not the win. It is a door held open for one short, specific conversation, and everything above is just how to get that conversation started.

Originally published on charliemorrison.dev.

This post was written with AI assistance and links to a free tool I built; the tool has an optional paid upgrade, so I may earn a small commission if you choose it — at no extra cost to you.

What Are Your Salary Expectations? I Tested 12 Answers

charlie-morrison — Wed, 01 Jul 2026 20:09:32 +0000

There is a piece of advice about the salary-expectations question that gets repeated in every career thread until it sounds like settled law: never name a number first. Deflect. Turn it back on them. Whoever says a figure first loses. I believed it too, right up until an application form refused to submit because the "Desired salary" field was required and would not accept the word "Negotiable." That little red asterisk does not care about your negotiating theory. So instead of trusting the folklore one more time, I ran the question through an actual test: I answered " what are your salary expectations?" twelve different ways, across the three places it actually gets asked, and tracked what each answer did to the conversation that followed.

The setup: four strategies, three channels

The question is not one situation, it is three, and they behave nothing alike. It shows up as a required field on an application form , as the closing question on a recruiter phone screen , and as a mid-conversation probe from the hiring manager once you are deeper in. I took four common strategies and ran each one through all three channels -- twelve combinations in total -- using my own job search plus a handful of applications volunteers let me run on their behalf, all for the same kind of senior backend role so the market range stayed constant.

The four strategies were the ones everyone actually argues about:

Deflect -- "I'd want to learn more about the role and scope before putting a number on it."
Single number -- one specific target figure, stated plainly.
Researched range -- a band drawn from market data, with the bottom of the range set to my actual target so the whole range sits above my floor.
Flip it back -- "What's the budget allocated for this role?"

I scored each attempt on two things that matter more than feeling clever: did the conversation advance to the next stage, and did the eventual number anchor at or above my target. An answer that feels powerful but gets you screened out has lost. An answer that feels meek but keeps you in the running and lands the number has won.

Where the "always deflect" rule falls apart

The first channel broke the rule outright. On application forms , deflection is not a strategy, it is a malfunction. Roughly half the forms I hit made "Desired salary" a required numeric field. You cannot type "negotiable," you cannot leave it blank, and a few systems silently parsed a deliberately low placeholder like 1 or 0 as your real expectation and used it to rank you out at the bottom. The flip-it-back strategy is equally useless here -- there is nobody on the other end of a text field to flip it to. On forms, only the two strategies that produce a number survive, and between them the researched range won every time: a range reads as informed rather than rigid, and because I had set its bottom edge to my true target, even the "low" end of what I typed was still a number I would happily accept.

This is the part the standard advice never mentions, because the standard advice was written for a phone call and then copied onto situations it does not fit. A required form field is a channel where naming a number first is mandatory, and pretending otherwise just gets your application deprioritized or your placeholder weaponized against you. The honest move is to treat the field as the first anchor of the negotiation and put a real, defensible range in it.

The recruiter screen: deflection survives, but barely

The recruiter phone screen is the one situation where the textbook advice has any footing -- and even there it is weaker than its reputation. Recruiters in 2026 are usually screening for budget fit before they spend a manager's time, so the salary question lands early and the subtext is "are you in our band or are we both wasting an afternoon." A clean deflection ("I'd love to hear the range you're working with first") worked about half the time: some recruiters happily volunteered the band, which is the dream outcome, because then they anchored. But the other half simply re-asked, slightly cooler, and a couple noted that a candidate who can't give a ballpark "doesn't know their market." Deflect twice and you read as evasive.

What consistently kept the screen moving was the researched range with a one-line reason -- "Based on the market for this role and my eleven years, I'm targeting the 165 to 185 band; happy to be flexible depending on the full package." It answers the actual question, it signals you have done your homework, and it leaves room. The flip-it-back move had a narrow but real use here: asking for their band first, once, before giving mine, often got the recruiter to anchor -- but if they bounced it back, I gave the range rather than dig in, because a standoff on a screening call is a fast way to not get a second call. The lesson across this channel was that you can lead with a question, but you cannot refuse to ever give a number; the range is your fallback the instant the deflection meets resistance.

The hiring manager: the only place a single number shines

Deeper in -- once a hiring manager is sold on you and the conversation turns to making it real -- the math flips. Here, where you have the upper hand because they want you specifically, a tighter, more confident answer paid off, and a wide range started to cost money. This is where the famous warning about ranges is actually true: state "165 to 185" to someone who is about to write the offer, and 165 is the number they hear, because the bottom of a range becomes the ceiling of their generosity. At the offer stage I switched to a single target number with justification and let silence do the rest.

To make that concrete I ran the exact scenario through the salary negotiation script generator on this site -- a senior backend role, current pay 145K, target 175K, data-driven tone -- to see what a clean, defensible version of the late-stage answer sounds like. Here is what it produced:

The generator's late-stage script names one target number, grounds it in market data and quantified wins -- and its own tips warn "never give a range" at the offer table, the exact opposite of what wins on a form.

Notice the tension in that screenshot, because it is the whole point of this experiment. The tool's tip list says, flatly, " Never give a range. The low end becomes the ceiling." That advice is correct -- for the moment it was written for, which is the offer-table negotiation the generator produces scripts for. It is also exactly wrong for the application form, where a range is the safest possible answer and a bare single number boxes you in before you know anything about the role. The same sentence is good advice and bad advice depending on the channel. That is why "never name a number first" keeps failing people: it is a real rule from one room being shouted into every other room.

Walk into the salary question with the script already written

The Job Search AI Toolkit bundles the salary negotiation script generator with the ATS resume checker, keyword extractor, and cover-letter and resume-bullet writers -- so you have a researched range for the form, a clean number for the offer, and the justification for both, before anyone asks.

Get the Job Search AI Toolkit -- $12

The one input every strategy depended on

None of the four strategies worked without a real number behind it, and the number is the part most people skip. A range you invented in your head is not research, it is a wish, and recruiters can hear the difference instantly. Before any of these answers I anchored every figure to public wage data -- the U.S. Bureau of Labor Statistics publishes occupational wage estimates you can pull for free from its wage data by area and occupation, which gives you a defensible floor and median that no recruiter will argue with. On top of that I checked role-specific ranges on the postings themselves (pay-transparency laws now put bands on a lot of listings) and triangulated. The range I quoted was always "market median to market-plus-my-evidence," never a guess.

That research is also what lets you set the bottom of your range honestly to your target. If the market median for the role is 165 and your real target is 165, then quoting "165 to 185" is not a trick -- it is a true statement where even the worst case keeps you whole. The strategy only works because the homework is real. For the deeper mechanics of when in the process to reveal information and how to frame the ask, Harvard Business School's Deepak Malhotra wrote the reference that most good advice is quietly cribbed from -- his 15 rules for negotiating a job offer -- and his core point lines up with what the test showed: your leverage and your information change as you move through the process, so the same question deserves a different answer at each stage.

What I actually say now

The experiment collapsed twelve attempts into a simple decision tree that depends only on which channel you are in:

Application form, required field: enter a researched range with the bottom set to your true target. Never leave it blank, never type a token low number, never write "negotiable" in a numeric field. This is a forced anchor -- make it a good one.
Recruiter screen: try once to get their band first ("What range is budgeted for the role?"). If they give it, you win. If they re-ask, give your researched range with a one-line reason and move on -- do not deflect twice.
Hiring manager / offer stage: switch to a single confident number with a justification, then stop talking. This is the one room where the "never give a range" warning is right, because the low end becomes the ceiling.

What disappeared from my answers entirely was the reflexive deflection. "I'd rather not say" is not a power move in 2026; on forms it is impossible, on screens it reads as evasive, and at the table it just delays the number you will have to give anyway. The skill is not refusing to answer -- it is answering with the right shape for the room. I confirmed the same pattern when I tracked 38 counter-offer negotiations: the offers that moved up were the ones anchored on evidence and stated plainly, not the ones where the candidate played coy. The companion run where I generated 30 negotiation scripts pointed the same direction -- a number with a reason beats a clever dodge almost every time.

And because the salary question rarely arrives alone -- it usually shows up tangled into a broader screening conversation -- it is worth rehearsing alongside the rest of the round rather than in isolation; the way I prep that whole sequence is in my interview-prep test of 31 strategies.

Common questions

What is the best answer to "what are your salary expectations"?

It depends on where you're asked. On a required application form, enter a researched range with the bottom set to your true target — never blank, never a token low number. On a recruiter screen, try once to get their budgeted range first, then give your researched range if they re-ask. At the offer stage with a hiring manager, switch to a single confident number with a justification and stop talking. There is no single line that works in all three places.

Should I give a salary range or a single number?

A range early (forms and recruiter screens), a single number late (offer negotiation). Early on, a range reads as informed and keeps you in the funnel; set its bottom to your real target so even the low end is acceptable. At the offer table, a range hurts you because the low end becomes the number they offer — there, name one figure and justify it.

Is it true you should never name a number first?

No — that advice was written for a live negotiation and copied onto situations it doesn't fit. On an application form the salary field is often required, so you must name a number first or get deprioritized. On a recruiter screen, refusing to give any figure can read as evasive. "Don't anchor first" only really applies once you're deep enough to have real bargaining power, and even then a researched anchor is often better than waiting.

How do I research a defensible salary range?

Start with public wage data — the U.S. Bureau of Labor Statistics publishes free occupational wage estimates by area, which gives you a floor and median no recruiter will dispute. Then read the bands on actual postings (pay-transparency laws put ranges on many listings now) and triangulate to a role-specific number. Your quoted range should run from the market median to market-plus-your-own-evidence, never a figure you guessed.

The honest summary, after twelve attempts: the salary-expectations question is not one question and there is no one answer. The advice that fails people treats a recruiter-call rule as a universal law and then watches it shatter against a required form field. Match the answer to the channel -- range on the form, range-after-one-deflection on the screen, single number at the table -- and anchor every figure to real wage data, and the question stops being a trap. It becomes the first place you get to set the terms.

If you want the pieces that make this quick under pressure, the salary negotiation script generator writes the offer-stage version with your numbers and tone, so the one room where a single figure matters most is the room you walk into already scripted.

Originally published on charliemorrison.dev.

This post was written with AI assistance and links to a free tool I built; the tool has an optional paid upgrade, so I may earn a small commission if you choose it — at no extra cost to you.

DEV Community: charlie-morrison

Telegram's 4096-character limit isn't characters. I measured it

How I tested it

The number is 4096. The unit is code points.

But the UTF-16 rule is real -- for offsets

Visible characters are not the unit either

Captions: same rule, different number, different error string

What this means in code

Building on Telegram for something lighter?

What I did not test

The short version

Questions I had before I measured

Telegram in Production -- the parts that bite you

More from the Telegram build log

Telegram Poll Limits: What I Measured Against the Live Bot API

How I tested it

The hard walls

The character cap counts characters, not bytes

Timers get rounded, not refused

There is no bold, no italics and no spoiler inside a poll

Quiz mode: one correct answer, whatever the field name suggests

Four switches worth knowing before your next round

Want the run sheet instead of the API?

What I actually changed after this

Running a whole night, not a single round?

FAQ

Related reading

13 Telegram Bots on One 1GB VPS: The Real RAM Numbers

What is actually on the machine

What a Telegram bot really costs in RAM

The biggest memory consumer was not a bot

The real ceiling is not memory

One process per bot, and why it is worth it

Measure your own box in one command

See a Mini App that needs no server at all

Not here to run a server?

FAQ

Related reading

I Sent 24 Requests to Telegram's Bot API to Find What Breaks a Group Game

How I tested it

The five things that break a round

1. The 100-character option cap hits the exact game you most want to poll

2. The option limit is 12, not the 10 you'll read everywhere

3. Quiz mode demands a right answer, so it's wrong for opinion games

4. Polls are anonymous by default, which silently kills Most Likely To

5. Two requests that succeed while doing the wrong thing

Two mechanics worth adding on purpose

The host protocol this adds up to

Try the free game first

Want the rounds already built for polls?

FAQ

Related reading

I Messaged 18 'Best' Telegram Game Bots. 7 Never Replied

How the test worked

The seven that said nothing

The eleven that answered

Why bots die quietly

The bug in my own test that nearly produced a fake result

The 15-second check you can do yourself

What this changed about the game I run

Test it yourself — it should answer instantly

FAQ

Related reading

I Generated a Month of Social Posts With One Free Tool — Here's the Mix That Held Up

The input I froze

The mix it enforced (and why it's right)

What the generated posts actually contained

What it can't do

The honest verdict

Skip the blank calendar entirely

FAQ

I Ran 4 Salary Negotiation Tones Through an AI Detector

The test: one offer, four tones, one detector

The scores

Why "Confident" read like a bot

Why "Data-Driven" read human

What this actually means for your next email

Generate the script, then make it sound like you.

One caveat about the number itself

FAQ