How to Tell If Someone Blocked You on Telegram

Your message went through. There is one tick, or two, or none at all depending on who you ask. Their profile photo is gone, their last seen says nothing useful, and you cannot decide whether you have been blocked or whether the person simply changed a setting three months ago and forgot about it.

The reason this is hard is deliberate. Telegram does not tell you that you have been blocked, and it never will, because telling you would defeat the point of the feature. What it does instead is refuse things, and the refusals are not all the same. Underneath the app, some of those refusals carry a code that says blocked and others carry a code that says privacy setting, and they are genuinely different codes.

That is the useful part of this subject and it is the part nobody writes about. The signals people repeat to each other are mostly weak, several of them are produced just as easily by a privacy setting you cannot see, and there are two or three that are actually reliable if you know what you are looking at.

Everything below was read from Telegram's own protocol documentation and public help pages on 10 August 2026, not remembered. Where the platform publishes nothing, that is said rather than filled in. One honest note before we start: there is no dedicated page describing the blocklist. The address exists and returns a page, but the page says it was never written, so the facts here are assembled from the individual operations and record definitions instead.

The Question Behind the Question

Before the signals, get the shape of the problem right, because most wrong answers come from asking the platform for something it was built not to answer.

The platform will never confirm it

There is no operation that asks whether a specific person has blocked you, and there is no flag on their profile that says so. This is not an oversight. A confirmation would turn blocking into a message, and the whole point of blocking is to stop sending messages to that person. Everything you can do is inference from refusals.

You can, however, see the other direction

The full profile record for a user carries a flag stating whether you have blocked them. That one is published, because it is your own state and your own client needs it to draw the interface. So the asymmetry is complete: your side of the relationship is a fact you can read, their side is a guess you have to build.

Why inference still works

It works because the platform is precise about failures even while it is silent about causes. Two different refusals that look identical in the app carry different codes underneath, and a few features refuse in a way that a privacy setting cannot reproduce. That is the whole method, and it is what the rest of this article is.

Telegram Never Says You Are Blocked

Start with what the sender is actually told, because this is where most confusion begins and where it can also end.

Two blocking errors, not one

When a message is refused for a blocking reason, the platform distinguishes two cases with two separate codes: one meaning you were blocked by this user, and one meaning you blocked this user. They are not interchangeable and a client that reads them can tell you exactly which side of the wall you are on. Most clients show the second and hide the first.

Privacy refusals are different codes again

An account that requires a subscription from strangers returns an error naming the subscription requirement. An account charging Stars for a first message returns one saying the peer only accepts paid messages. A chat you simply cannot write in returns another, and a deleted account returns another again. None of these mean blocked, and all of them produce the same silence in a badly built interface. We walked the whole set in our piece on what each privacy setting actually blocks.

What this means for you as a human user

Your app is deciding how much of that to show you, and most apps show almost none of it. So the first honest answer to why can I not tell is that the information exists but your client has chosen not to surface it. That is worth knowing before you spend an evening testing theories.

What the Protocol Actually Records

The blocklist is a real stored object with real fields, and reading those fields tells you what the feature is and is not.

A block is a dated entry

Each blocked peer is stored as a record with the peer and the date the block happened. Not a rule, not an audience, a timestamped entry in a list. That is why blocking behaves so differently from the privacy keys, which are rules evaluated against a category of people rather than entries naming one.

The presence of a date is the detail worth pausing on. Privacy keys carry no history; you cannot ask when you last changed who may add you to groups. A block does carry one, which makes the blocklist the only part of this area that remembers a sequence of events rather than only a current state.

The list is long by design, and blocking fails only in ordinary ways

The operation that fetches your blocklist takes an offset and a limit, the same shape used everywhere for collections expected to grow. Nothing suggests a small cap, and no published number limits how many accounts you may block, which is itself informative: the feature was built for people who use it often rather than once.

The block operation returns errors for an invalid peer, an invalid contact, a deleted account and a private channel you have not joined. None of them are about permission. In other words the platform does not stop you from blocking people; it only stops you from blocking things that do not exist, and that is the entire failure surface.

The Signal People Trust Most Is the Weakest

Almost every guide leads with last seen. It is the least reliable thing in this entire article, and the documentation explains exactly why.

Vague status has three innocent causes

Seeing recently, last week or last month instead of an exact time can mean they blocked you. It can equally mean they set last seen to nobody or to contacts only, which is a common default for anyone who has ever tidied their settings. It can also mean nothing about them at all, which is the third cause and the one nobody knows.

There is a fourth wrinkle underneath those three. Telegram's help page states that regardless of the last seen setting, a person appears online for roughly thirty seconds when they send a message in a shared chat, when they read a message in a one to one chat, or when their client broadcasts a typing indicator. So a contact who looks permanently offline may simply be someone who never does any of those three things in your direction, and a brief flicker of online is not a sign that a wall came down.

The third cause is your own setting

The vague status carries a flag whose published description says the exact status is actually available, but to see it you must either buy a subscription or allow that person to see your own exact last online time. So the vagueness can be a consequence of your configuration, reported back to you as if it were theirs. If you hid your last seen from people and then went looking for who blocked you, you built the fog yourself.

Why this matters more than it sounds

This single flag invalidates the most repeated test on the internet. Last seen going vague is not evidence. It is a state with at least three causes, one of which is you. Our separate piece on what last seen actually reports covers the field itself in more detail.

The Profile Photo Signal

The second most repeated test, and it fails for a subtler reason than the first.

A missing photo is not proof

The photo has its own privacy key with its own audience. Someone who set it to contacts only will show you nothing, whether or not they have any opinion about you. Same picture, same absence, completely different cause.

The fallback photo makes it worse

The profile record supports a fallback image shown to people outside the audience for the real one. So a person can appear to have changed their photo when they have not, and you can be looking at a placeholder that was put there for strangers in general. Treating a photo change as a personal signal is guesswork twice over.

The Signals That Are Actually Reliable

Three things behave differently under a block than under any privacy setting, and together they are close to conclusive.

The message refusal itself

This is the strongest one, because it is the only signal the platform generates specifically for this case. If your client surfaces errors at all, a refusal citing being blocked is exactly that and nothing else. No privacy key produces that code, and neither does a rate limit.

It is also the fastest. One message settles a question people otherwise spend days circling, and the reason they circle is not that the answer is hidden but that it is delivered in a layer their app throws away. If you have ever wondered why an operator answers this in seconds while an ordinary user cannot, that is the entire difference.

Common groups going to zero

The full profile record carries a count of chats you have in common, and it is a plain number rather than an inference. Blocking does not remove either of you from shared groups, so a genuine zero on someone you used to share a group with means one of you left that group, not that anyone was blocked.

This is worth stating in reverse, because the reverse is what circulates: people cite empty common groups as proof of a block, and it proves nothing of the kind. If anything it is evidence against, since a real block would have left the shared membership exactly where it was.

The chat bar above a first conversation

Telegram publishes a small set of facts above a chat with someone new, and the list is longer than the bar looks. It says whether you are allowed to block this person, whether you can add them as a contact, whether you can still report them for spam, whether the chat was archived automatically because of their privacy settings, the month the account was registered, the country of the phone number, and when the name and the photo were last changed. If that person charges Stars to receive messages, the required amount appears there too, and it appears only to you.

Two of those fields carry more weight than the rest. That the block control is a published permission rather than an assumption means the app is being told whether the action is available at all. And that the automatic archive state is published means you can tell the difference between someone ignoring you and a setting that filed you away before they ever saw the message, which is a distinction people agonise over without knowing it is written down. We covered how this bar is used to judge unknown accounts in our piece on checking an account before you pay.

Calls Separate Blocking From Privacy

The call system is the cleanest diagnostic on the platform, and almost nobody uses it that way.

Two different refusals, published side by side

Requesting a call can fail with an error meaning you were blocked by this user, or with a different error meaning the user's privacy settings do not allow it. Both are refusals, both are in the same documented list, and they are not the same code. A client that reads them can distinguish a block from a call privacy setting with certainty.

The profile also publishes the call state

Two flags on the full profile say whether the person can make calls at all and whether their privacy settings allow you to call them. So part of this can be read before you try. What the profile does not do is tell you the difference between blocked and disallowed, which is the part only the attempt reveals.

The same profile record carries a third flag of the same kind, saying whether the person refuses voice messages in a private chat. It is a useful reminder that most of what feels like rejection on this platform is published as a capability rather than discovered as a failure. Between calls, voice messages, read dates and the subscription requirement, four separate refusals are announced in advance on the profile, and none of them is a block.

Read Dates Have Two Different Refusals

The read date system is the only place where the platform tells you the restriction is yours, and it is a small masterpiece of clarity that almost nobody sees.

Their setting versus your setting

Asking for the exact time a message was read can fail two ways. One error says the user's privacy settings do not allow it. A second, separate error says you cannot fetch this because you have disallowed other users from doing the same for your messages, and the fix is to allow people to see your exact last online status. Two codes, two causes, no ambiguity.

The state is readable in advance

The full profile carries a flag saying read dates are private for this person, so a client can present the situation before you ask rather than after you fail. The pattern across this whole area is the same: the platform hides the value and publishes the fact that a value is hidden.

Other ordinary reasons it fails

The same operation returns errors for a message that has not been read yet and for a message that is simply too old for the information to still exist. Neither has anything to do with blocking, and both are easy to mistake for something personal when your client shows a blank instead of a reason.

There Are Two Blocklists, Not One

This is the fact most likely to be new even to people who use the platform daily.

The main list and the story list

The block, unblock and fetch operations all take a flag choosing between the main blocklist and a separate list that governs who can see your stories. Setting the flag adds the person to the story list; leaving it off adds them to the main one. They are independent collections.

The profile publishes both states separately

The full profile record carries one flag for whether you have blocked this user and a different flag for whether you have blocked them from seeing your stories. Two flags, because they are two decisions. Someone can be fully blocked, story blocked, both, or neither.

Why this creates confusion in practice

A person who is story blocked but not blocked can still message you and still sees an ordinary profile. From their side nothing about the relationship looks unusual; they simply never see a story. If you have ever wondered why someone reacts to everything except your stories, this is the mechanism, and it has nothing to do with the algorithm.

A Third List Almost Nobody Knows About

Two blocklists is already more than most people expect. There is also a third operation in this family, and it is the one that explains a specific kind of silence.

Blocking someone out of a discussion thread

A separate operation exists whose published purpose is to stop getting notifications about a certain user's discussion replies in the replies feed. It is not the main blocklist and it is not the story list. It is a targeted mute on one person's replies underneath channel posts, and it exists because channel discussion threads generate a category of unwanted contact that ordinary blocking was never shaped for.

Why the platform needed a third mechanism

The reason is structural. A channel post's discussion happens in a linked group, and the replies feed collects responses to your posts across all of them. Someone replying there is not messaging you privately, so a private chat block is the wrong instrument; the reply is public and stays public. What the operation removes is the notification path, not the reply itself.

What this means if you run a channel

If you publish and the discussion is busy, the noise you want gone is usually not coming from people you would block outright. It is from a handful of accounts replying to everything. That is what this operation is for, and it is a good example of why the honest answer to did they block me is often that a completely different mechanism was used on a completely different surface. Channel side automation, including a first response to the people who do write in, lives in our bot panel.

What Blocking Does Not Do

The list of things blocking leaves untouched is longer than most people expect, and every item on it is a reason someone concludes wrongly that they were not blocked.

It does not remove history, and it does not eject anyone

The conversation stays where it is on both sides. Nothing is deleted, nothing is hidden, and either party can scroll back through everything that was ever said. Blocking is forward looking only, which is the opposite of what most people assume when they use it in anger.

Group membership is equally untouched. Two people who have blocked each other can remain members of the same group and both keep posting into it, and neither of them is notified of anything. What each sees of the other inside that group is a separate question covered further down, but the membership itself never moves.

It does not stop a mention or a forward

Content you wrote can still be forwarded by other people into places the blocked person can read, and your name can still appear in conversations they are part of. Blocking governs the direct channel between two accounts, not the circulation of what either of them has already said.

What Happens to Messages Already Sent

A common worry, and the answer is simpler than the rumours.

Nothing is recalled, and new attempts are refused at the source

Messages delivered before a block stay delivered. There is no operation that unsends a message as a side effect of blocking, and the block record itself carries only a peer and a date. Whatever arrived, arrived, and no amount of blocking afterwards reaches back for it.

The refusal happens when you try to send, not silently somewhere in the middle. This is the point worth internalising if you are used to platforms that quietly discard. Telegram does not accept and drop; it declines and says so in a code, even when your app renders that code as nothing at all.

That distinction decides what a tick means. A single tick means the platform accepted the message and it has not been read yet, which is an ordinary state and not a symptom. If a block were in the way the message would not have been accepted in the first place, so counting ticks to detect a block is measuring the wrong end of the process. The question is never how many ticks appeared, it is whether the send was refused at all.

Groups Are the Exception

Everything above describes private chats. Shared groups follow different rules and this is where most contradictory advice comes from.

Blocking is a private channel decision

The blocklist governs the direct relationship. Inside a group both accounts are participants, and participation is managed by the group's own permissions and by its administrators, not by what two members think of each other. Someone who blocked you can still see the group and so can you, and both of you can keep posting into it.

There is a second consequence that catches people out when they are building an audience rather than having a conversation. If you are adding members from one group into another, a person who blocked you privately is not thereby removed from the source group and not thereby excluded from a member list; whether they can be added is decided by their group invite privacy key, which is a different switch entirely. Our member sourcing tool reports those two refusal types separately, because collapsing them hides which one you are actually hitting.

Being removed from a group is a different action

If you can no longer see a group at all, that is a moderation action taken by an administrator, not a personal block, and it has its own separate mechanics. We covered the administrative side in what each administrator right actually grants, and the invitation side in how invite links behave.

Blocking, Reporting and Restricting Are Three Things

These get used interchangeably in conversation and they are completely separate systems with separate consequences.

Blocking is between two accounts

It is your private decision, it affects nobody else, and no moderator ever sees it. It is instantly reversible by you and by nobody else, and it produces no record anywhere outside your own account. Nothing about it is escalation; it is the smallest and most local action in this whole area, which is precisely why it is the right one when a single person is the problem.

Reporting goes to the platform

Reporting submits a reason from a published set and sends it for review. It is a request for someone else to act, it does not stop the person contacting you, and blocking and reporting are usually done together precisely because neither one does the other's job.

The set of reasons is fixed rather than free text, which is why the report screen offers a list instead of a box. It also means a report is a classification, not a complaint: you are telling the platform which category the behaviour falls into, and the categories are the same for everybody. Whether you can still report a given account is one of the fields published in the bar above the chat, so the option can be absent without anything having gone wrong.

Restriction is the platform acting on an account

An account that has been restricted for unsolicited messaging is in a completely different state, imposed by the platform rather than by any individual, and it has its own appeal route. If your messages started failing to everyone rather than to one person, you are almost certainly in this third case and not being blocked at all; the route out is in our guide to lifting a spam restriction.

What This Means If You Send at Volume

For anyone running outreach rather than a personal chat, the whole subject changes shape, because you are not asking about one person, you are reading a distribution.

Blocks are a rate, not an event

At any real volume some proportion of recipients will have blocked the sending account, and that proportion is information about the account and the message rather than about any individual. Reading it as a per person mystery wastes the signal.

It also changes what a good day looks like. A run with zero block refusals across thousands of recipients is usually not a clean run, it is a run that never reached anybody, because any list that has been contacted before contains some accounts that closed the door. The number worth watching is not whether it exists but whether it is moving, and in which direction relative to everything else you changed that week.

The codes let you separate causes

This is the practical payoff of everything above. A run that fails will fail for several different reasons at once: privacy walls, paid message requirements, blocks, deleted accounts, restrictions, rate limits. Because the platform returns a distinct code for each, a well built sender can split the failures instead of reporting one number. Our campaign tool records the refusal reason per recipient for exactly this reason, and our note on sending at volume shows what the split looks like.

A rising block rate is a message about the message

If refusals citing blocks climb across a run while the targeting stays constant, the variable that changed is what you wrote or how often you sent it. This is one of the few genuinely early warnings available, and it usually arrives before a restriction does. The preventive side is covered in avoiding restrictions during outreach, and if you operate several accounts, our multi account panel keeps the per account picture in one place instead of one phone at a time.

Unblocking Does Not Restore Anything Else

The reverse operation is narrower than people assume, which produces a specific and very common confusion.

One relationship, restored

Unblocking removes the entry from the list. That is all it does. It does not change any privacy key, it does not re add anyone to your contacts, and it does not undo a story block if you set one, because that is a separate list with its own flag.

The change is pushed rather than pulled. When your blocklist changes the platform emits an update to every session signed into the account, which is why a block performed on a phone shows up on the desktop within seconds. That matters for anyone sharing operational access: the list is account state, not device state, and everyone signed in is looking at the same list.

Why someone still cannot reach you

If you unblock a person and they still cannot add you to a group, still cannot see your last seen, or still cannot send you a voice message, nothing has failed. Those are privacy keys, they were always the reason for those particular limits, and the block was never what stopped them. Two systems, two states, and only one of them was ever involved.

A Test That Actually Settles It

If you genuinely need an answer rather than a theory, there is a short sequence that uses the reliable signals and ignores the weak ones.

Start with the refusal, not the profile

Send one short message and look at whether anything is refused, and if your client shows a reason, read it. A refusal citing a block is conclusive. A refusal citing a subscription requirement or paid messages means a privacy wall, not a block, and that distinction is the entire test.

Then try a call

A call request separates the two cases explicitly, because being blocked and being disallowed by privacy settings return different errors from the same operation. This is the second best signal available and it takes a single attempt. It also works when the message test was inconclusive, since the call path and the message path are refused by different systems and rarely fail for the same reason at the same time.

Stop there

Do not build a case out of photos, last seen or common groups, because all three have innocent causes and one of them can be caused by your own settings. If the first two steps did not give you an answer, the honest conclusion is that you do not have one.

A second account to test with is the usual next idea and it is worth thinking about carefully. It tells you less than people expect, because what you learn is how that account is treated rather than how yours is, and the two differ the moment either one carries a privacy setting or a history. It also costs more than people expect, since a fresh account writing to a stranger for the first time is exactly the pattern the platform watches most closely, and the account you actually use for work is the one that pays for a wrong guess. We covered why that gets expensive in running more than one account.

Frequently Asked Questions

Does Telegram tell you when someone blocks you

No, and there is no operation that asks. Your own profile record shows whether you blocked someone else, but the reverse direction is not published to you. Everything you can determine comes from how specific actions are refused.

Is a vague last seen proof that I was blocked

No. It has at least three causes: a block, their last seen privacy setting, or your own setting. The documentation states that hiding your exact last online time from people removes your ability to see theirs unless you hold a subscription, and the status you receive carries a marker showing that is why.

Can I still see our old messages after being blocked

Yes. The conversation stays intact on both sides and nothing is deleted. Blocking only affects what happens next, and the stored block record contains just the peer and the date.

What is the difference between blocking someone and blocking them from stories

They are two separate lists. The block operation takes a flag choosing which one you are adding to, and the profile carries a separate indicator for each. A person can be blocked from stories only, in which case everything else between you works normally.

Will blocking someone remove them from my groups

No. Group membership is managed by the group's permissions and administrators. Two accounts that have blocked each other can remain members of the same group and both keep posting in it.

Why did my message fail with no explanation at all

Because your client is not showing the reason. The platform returns distinct codes for being blocked, for having blocked the other person, for privacy requirements, for paid messages and for deleted accounts. The information exists; the interface chose not to display it.

Does unblocking put everything back

Only the block itself. Privacy settings, contact status and any story block are separate and are untouched by unblocking, which is why someone you unblock may still be unable to add you to a group or see your last seen.

Is there a limit on how many people I can block

None is published. The operation that fetches your blocklist is paged with an offset and a limit like any long list, which implies the list is expected to grow, but no maximum appears in the documentation.

My messages started failing to everyone, is that a mass block

Almost certainly not. Failures against one person point at that relationship; failures against everyone point at your account being restricted, which is a platform action with its own appeal path and nothing to do with anyone's blocklist.