PageLab is operated by Orbyt LLC, a New York limited liability company. This page states the minimum age for a PageLab account, how an account’s age tier is established and what it is allowed to do, and PageLab’s standards against child sexual abuse and exploitation — what is prohibited, how to report it, and what happens when it is reported.
The minimum age is 13
You must be at least 13 to hold a PageLab account. There is no younger tier, no parental route in, and no version of the product for under-13s.
- The refusal happens on our servers, not on the screen. The date you enter is judged by the API before an account exists, and the refusal it produces is re-checked on every path that can create one — email sign-up, Google sign-in, and the website. On the same installation the answer you gave is the one that is applied: a client that later sends a less restrictive date than you typed does not get a less restrictive result. An account cannot be created at all through the sign-up form without an age having been registered first — the request is refused, not quietly let through. Signing in with Google or Apple carries no age information from the provider, so those accounts start as unknown until something tells us otherwise.
- A refusal is recorded, and it binds to the device. Closing the app and answering again does not work: the refusal is kept against the installation, and it is checked before anything the next attempt claims about a date, so an immediate retry with a different answer fails rather than succeeding. Where a sign-in provider has already given us an address, the refusal is kept against that too. We do not bind it to an address someone merely typed — that would let anyone lock a stranger out of signing up by entering their address with a child's date of birth. The practical limit is honest: the record is kept against the installation as the app reports it, so a client that presents itself as a new installation is treated as one. We would rather say so than imply a wall that is not there. It lapses on its own after about six months — a child refused today has a birthday coming, and nobody should have to remember to clear a record.
- Borderline ages round down. We ask for a month and a year, never a day, and we assume the end of the birth month. Someone still in the month they were born in is treated as not yet having had that birthday, which errs toward turning away a borderline 12-year-old rather than admitting one.
- Nothing personal is collected before the question is answered. The age screen runs before an email address, a display name, a photo or a notification permission is asked for, so a person we are going to refuse is never asked to hand anything over first.
We will not overstate this. It is friction, not proof of identity: someone determined enough, with a new address and a new device, can get past it, and the same is true of every commercial age-assurance product on the market. What it does reliably defeat is the immediate retry.
How an account’s age tier is established
There are exactly two ways.
- A signal from the app store. Where the platform can tell us that the account holder is an adult, and can say how it established that, we use that answer and it outranks anything typed into the product. This signal does not exist in every country, on every device or for every account.
- A neutral date screen, as a fallback. Month and year, with no pre-filled value that would pass, no drop-down that starts at a passing year, and no “you must be 13 or over” warning shown before you answer — a warning shown first is an instruction on what to type. The explanation appears on the refusal, where it belongs.
A date you type can never overturn what the platform has told us, and can never free an account the platform has said is a child’s. Between the two signals the platform always wins. A typed date is accepted on its own only where the platform has said nothing at all — which is the ordinary case, because the app-store signal does not yet exist in most countries.
Where a typed date is all we have, we act on it in both directions: an under-18 date puts the account on the restricted tier, and an 18-or-over date does not. We would rather say that plainly than describe a stricter product than the one we ship. Two things bound it. A date that would relax an account is refused outright if the platform has already answered, so a teenager whose device says they are a child cannot type their way out. And an account that is already on the restricted tier cannot be released by typing a second, different date — only the platform, or the passage of time (below), moves it back.
Accounts we have never been able to ask — no platform signal, no date — are not treated as children. They are treated as unknown, which is the ordinary, unrestricted state of the product. We think guessing that an adult is a child, at the scale of everybody we cannot assure, would be a worse answer than saying we do not know.
The restricted tier ends when it stops being true
A reader who tells us they are fifteen should not still be restricted at twenty-five. When a typed date puts an account on the restricted tier, we work out from that same date the month the restriction stops applying, store that one date, and lift the restriction when it arrives. The account returns to the ordinary unknown state — not to a confirmed adult one, because nobody ever confirmed it.
This is not a self-declaration unlocking anything. The date is fixed at the moment the reader restricted themselves and nothing they say afterwards can move it. A platform signal saying the account holder is an adult also lifts the restriction, at any time.
We never store a date of birth
We keep the conclusion, not the input. Three things are recorded against an account: which age tier it is on, how that was established, and when. The date you typed is used to reach that answer and is then discarded — it is not written to the account, not written to a log, and not echoed back to the client. A refusal record holds a one-way hash and an expiry date, nothing else.
Where a typed date puts an account on the restricted tier we also keep the single future month in which that restriction ends, so that it can end. That is one date, to the month, and it is all it says: not a minor after this point. It is not a birthday, we do not keep anything that could be combined with it to make one, and it is derived once and then the date you typed is discarded like any other.
This is deliberate and it has a plain consequence: a breach of PageLab’s age data would disclose nobody’s birthday, because there is none to disclose.
What a restricted account can and cannot do
Accounts we have been told belong to someone under 18 are on a restricted tier. Read that as a statement about the account, not a claim about the person: an age signal can be wrong, and an account can be restricted by an answer the person holding it never gave.
The principle is books stay open, people close. The entire reading product is unaffected:
- Searching and browsing the catalogue; book, edition, series and author pages.
- Shelves, ratings, reviews, quotes and private notes.
- Reading progress, streaks, challenges and the year in review.
- The cover studio, library import and export, and every setting.
What closes is the ability to be found, contacted or profiled by a stranger:
- Direct messages are limited to accepted connections, in both directions. A stranger cannot open a conversation with a restricted account, and a restricted account cannot open one with a stranger; neither can send into a thread that was open before. What remains is messaging between two people who have each approved the other. Unsolicited contact — the part of private messaging that carries the risk — is what closes.
- The profile is visible only to accepted connections. A connection means a follow request that both people accepted. Two people happening to follow each other is not a connection and does not open a profile.
- Follow requests always need approval, and that cannot be switched off. Declining a request is silent — the person who asked is not told — so turning someone down never has to be a confrontation.
- Never offered to anyone else through a surface that suggests people:
readers-like-you, taste matching, reader search and any rail that puts a person in front
of another person. No stranger is handed a restricted account by any of them, and it
cannot be found by searching for a name.
Three of those four are switched off in the other direction as well: a restricted account is not shown readers-like-you, taste matching or a people rail, because a rail puts a person in front of you that you never asked for. Reader search still works for them, and returns only adults. That one is deliberate and not an oversight. Because nobody can find a restricted account, a connection can only ever be requested by the person who is restricted — and searching a name is the only way to find by name the person to ask. There is one other route to a profile, the friend code, and it does not substitute for this one: a code has to be handed over by its owner, so it can reach someone you have already met and never someone you have not. Closing name search would leave a restricted account able to connect only with people who had already given it a code, which for most of them is nobody — and that would make every protection below unreachable rather than optional.
The one place a restricted account still appears is in the follower and following lists of someone who has already accepted them, who can open their profile directly in any case. Hiding it there did not protect anybody: it hid the account from its own list too, and left an approved connection unable to start the conversation both people had agreed to. - Reading records are private by default.
- Tagging and mentioning are off.
- Images are not shown to, and cannot be downloaded by, anyone who is not an accepted connection — including the profile picture and the profile cover, not only attachments.
- Groups and buddy reads are read-only. A public group can still be read; creating, joining, following, posting, replying, reacting and inviting are closed. Leaving is not: an account that was already in a group can always get out of it, and can always decline an invitation. A rule meant to protect someone must never take away the way out.
- No recommendation model runs over a restricted account. The personalised feed is not narrowed for these accounts — it is withheld entirely, and nothing about the account is fed into a model. Trending remains available and is ordered by what is popular across PageLab as a whole; it is the same list for everybody and is computed from nothing about the person reading it. Following and group feeds are in time order.
- Notifications are transactional only. No digests, no re-engagement nudges, nothing that exists to pull someone back into the app. Notifications that would arrive between midnight and 6am local time are held until morning; they wait in the inbox rather than waking anyone up — where we know the account’s time zone, which the app reports when it registers for notifications.
All of this is enforced by the API, not by the app. Hiding a button is not a restriction — a request that should be refused is refused at the server, whatever is making it.
Child sexual abuse and exploitation is prohibited
PageLab prohibits child sexual abuse material, and conduct that sexualises, solicits, grooms or exploits a person under 18. This applies everywhere on PageLab without exception: posts and replies, reviews, quotes, groups and buddy reads, direct messages, uploaded images, and profile pictures and covers. No maturity marking, age gate, fictional framing or private setting makes it permissible.
The wider rules on what may be posted are on the Content Policy page. This section is about the one category that is handled differently from everything else.
How to report it
- In the product. Use the report control on the item itself. Both clients carry it in the same places: a post, a reply, a reader’s profile, a profile cover image, a direct message, and a group. In the Android app it is the overflow menu on a post, a reply, a profile or a group, and a long press on a message inside a conversation; on the website it is the same overflow menu, and a flag beside the message. A direct message and a group could not be reported from either client until recently — this page said so, and it no longer has to.
- The reason to choose is Sexual content involving minors, and it is offered wherever the report sheet asks for a reason — on a direct message and on a group as much as on a post. It is worded identically in the Android app and on the website, so the same thing is reported the same way from either.
- A message is reported from the conversation it is in, so what reaches us is the message itself rather than a description of it. The control appears only on messages someone else sent: a report of your own message is refused, so offering it would be a control that could only fail.
- It works from any signed-in account. Reporting is deliberately not behind email verification, and it is deliberately not closed to restricted accounts — a report about a direct message stays available whether or not that account can send one. Someone who has been harmed must not lose the tool because of the state of their own account.
- In writing. Correspondence about child safety — from a parent or guardian, from law enforcement, or from NCMEC — should be sent to Orbyt LLC at the child-safety contact listed on the Legal Contact page. The in-product report is faster, and it is the only route that reaches the review queue directly.
What happens to a report
- It reaches a person. Reports go into a moderation queue that staff work through; nothing in this category is closed by a counter.
- It acts before anyone has looked. This is the only report reason that takes effect on a single report from a single account: the post immediately stops being distributed. That costs the author reach, not access to their own writing, and a moderator can undo it. We would rather be temporarily wrong about a post than leave real material circulating while a queue drains.
- Only the most senior staff can see it. Reports in this category are invisible to ordinary moderators — not merely un-actionable, but absent from the queue, from the case view, from ban proposals and from the audit trail’s reason field. Adjudicating one means opening the material, so only App Admin level and above may do it. A reviewer who has taken a case can see the reported image even where the age tier would otherwise hide it — but only that item, only while the case is open, and never a case they filed themselves. The exception attaches to the case, not to the badge, so there is always a record of why something was seen.
- Removing the post is not enough, so we block the file. Uploads are stored by a hash of their contents, which means a confirmed file can be blocked by that hash: retroactively, across every post, message and profile that points at those bytes, and against any future attempt to upload the same file again. The block is a record rather than a state of the disk, so it survives the file being moved, cleaned up, restored, or the storage being rebuilt.
Preservation, and why some things are not deleted
Confirmed child sexual abuse material is reported to the CyberTipline operated by the National Center for Missing & Exploited Children, and the material and the account records are preserved rather than erased.
- An account can be placed under a retention hold. While a hold is live, account erasure, the scheduled deletion sweep, media clean-up and the routine pruning of IP records all refuse to run. That refusal is built to fail in the safe direction: a hold we cannot read is treated as a hold.
- A hold placed because a report was filed to NCMEC runs for at least twelve months and cannot be shortened, lifted early, or quietly downgraded to a weaker reason by a later action.
- Every hold has an expiry date. None of them is open-ended. Retention that nobody has to remember to end is how a well-meant hold turns into keeping someone’s data forever with no basis.
- A retention hold outranks a deletion request, including a request made by the account holder. The deletion page answers identically whatever address is typed into it, so that it cannot be used to discover who has an account here — which also means it cannot tell you that a hold is why no code arrived. Ask us directly and we will say so, rather than promise a date we cannot keep.
An account we learn is under 13
Staff read user content, so under-13 accounts will occasionally surface — through a report, or through something someone posts. When that happens the account is deleted, not suspended. Deleting is a complete answer: it means we are not holding a child’s data at all.
- It is a distinct action, restricted to App Admin level and above, and it is recorded in the permanent moderation log.
- It does not use the ordinary 30-day deletion window, because signing in cancels that window — the erasure is carried out directly.
- It does not mark the person as a banned offender. It does record a refusal, so the same address cannot immediately register again.
- If the account is under a retention hold, the erasure is refused and recorded rather than performed. A live preservation obligation outranks it, and we would rather report the conflict than resolve it by destroying evidence.
What this page does not cover
- The agreement between you and PageLab, and questions of governing law and liability — Terms of Service.
- What PageLab collects generally, who it goes to, and how to have it deleted — Privacy Policy.
- What may and may not be posted, and how reports are handled generally — Content Policy.
- Where to send legal notices, and how copyright complaints are handled — Legal Contact.