Florida and Texas social media bans for minors: three laws not to confuse

Florida and Texas social media bans for minors are not interchangeable app requirements. Florida HB 3, Texas HB 18 and Texas HB 1181 address different subjects, and confusing them can send a product team toward the wrong age gate, consent flow or account restriction.

This article identifies those three laws, explains the distinctions that matter for app planning, and separates them from federal children's privacy requirements. It is a statutory identity and product-planning guide, not a report on the current injunction status of Florida HB 3 or Texas HB 18, or a complete determination that your app is covered.

The three laws, by name

Start with the legal citation, not a ticket labeled “state minors ban.” A bill number identifies legislation, while a statutory citation helps your team locate the provisions it needs to evaluate. Neither tells you, by itself, whether a particular app or feature falls within the law.

The important correction is that Texas HB 1181 is not the SCOPE Act. It is not a general rule requiring parental consent before a minor can create a social-media account. A product brief that attaches those account-consent duties to HB 1181 has identified the wrong law.

The table gives you locators, not a substitute for the statutory definitions. Before applying any requirement, have the legal review identify the covered entity, the covered activity, relevant exclusions and the particular provision being evaluated. A product's marketing label—social network, messaging app or shopping service—does not complete that analysis.

Keep a separate entry for each law in your requirements document. Do not collapse the entries merely because each mentions children, online services or age. Treat them as separate age restrictions laws, with their own scope questions and product consequences.

Florida HB 3: account eligibility is a separate question

Florida's social-media account framework belongs in Fla. Stat. § 501.1736. Its statutory age structure distinguishes children under 14 from children who are 14 or 15: the former face an account prohibition on covered platforms, while the latter require parental consent. Those categories should not be flattened into a single “minor with consent” setting.

For planning purposes, the difference is fundamental. Parental permission and eligibility are not the same thing. If a restriction prohibits an account for an age group, collecting permission does not turn that prohibited account into an eligible one.

Keep the Florida account decision separate from any federal decision about collecting a child's personal information. A parent consenting to data collection is not necessarily authorizing an account under state law. Likewise, an account decision does not settle what information the service may collect or disclose.

There is another distinction within the Florida planning work: an age category is not the same as a coverage determination. Knowing a user's age does not establish that the service meets the statute's definition of a covered platform. The team needs both answers before it can describe a feature as implementing the relevant restriction.

A useful Florida-specific product note should state:

Do not turn this statutory description into a claim about present enforceability. A release decision needs its own documented legal assessment of the provisions and any applicable court orders. That assessment should not be inferred from the presence of an age branch in a diagram.

The practical lesson is narrower than “build a Florida age gate.” It is to preserve the difference between an account prohibition and a permission requirement so that a shared consent component cannot accidentally erase it.

Texas HB 18: identify the SCOPE Act correctly

Texas's law for this minors-and-digital-services discussion is HB 18, the SCOPE Act, codified in Texas Business and Commerce Code chapter 509. That is the law your team should identify when researching its covered digital-service duties for minors—not HB 1181.

The Texas attorney general's SCOPE Act overview states an effective date of September 1, 2024, and describes protections for children under 18 against harmful content and data collection practices. It also describes a violation as a deceptive trade practice enforceable only by the Consumer Protection Division of the Office of the Attorney General of Texas, which may seek injunctive relief, civil penalties of up to $10,000 per violation, and attorneys' fees.

That description identifies the law and its stated enforcement channel. It does not justify treating every provision as currently enforceable, or every app as covered. Keep the statutory effective date, the scope analysis and the enforcement-status assessment in different fields in the legal handoff.

The SCOPE Act also should not be reduced to a signup screen. Its subject includes children's data practices, so the relevant product inventory can extend beyond account creation. Advertising integrations, analytics, profile fields and parental account tools are sensible places to examine when mapping a service's behavior to the provisions under review.

That inventory is practical preparation, not a claim that every listed feature triggers a particular duty. Ask counsel to connect each proposed requirement to the applicable statutory language. Then ask engineering to identify the systems that actually implement that requirement.

For example, changing a signup permission flag will not necessarily change what an analytics integration receives. If the legal analysis identifies a data-handling obligation, the implementation needs to reach the data path—not just the account interface.

Texas HB 1181: sexual-content access is not account consent

Texas HB 1181 addresses a different question: access to certain commercial websites publishing sexually explicit material that is obscene to minors. Its age-verification requirement should not be presented as a general social-media account rule.

The Supreme Court's HB 1181 decision, Free Speech Coalition v. Paxton, describes the law as requiring certain commercial websites publishing that material to verify that visitors are 18 or older. The Court upheld the law under intermediate scrutiny because it only incidentally burdens adults' protected speech.

That holding matters to the law the Court actually reviewed. It is not a ruling that every Texas social-media age restriction is valid, and it does not decide the enforceability of Florida HB 3 or Texas HB 18. Do not transfer the outcome from one statute to another because both involve age verification.

The product distinction is equally important. An adult-access verification requirement asks whether a visitor satisfies an age condition for access to covered material. A parental-consent mechanism asks whether a parent has authorized something for a child. Those mechanisms answer different questions.

Parental permission should not be treated as an alternative way for a child to pass an adult-access restriction. Conversely, an adult-age result does not establish a parent-child relationship or record permission for a child's account.

If an app team encounters HB 1181 during legal research, the next question is whether the service's activities fall within that statute's coverage. The next question is not which parental-consent provider to buy. Keep any HB 1181 access-control analysis separate from the SCOPE Act account and data analysis.

A service could require review under more than one law. Separation does not mean choosing whichever statute seems easiest; it means evaluating each potentially applicable law without borrowing duties, exceptions or court outcomes from another.

COPPA: a federal privacy layer, not a universal permission slip

The Children's Online Privacy Protection Act and its implementing COPPA Rule, 16 CFR Part 312, add a separate federal analysis. The Federal Trade Commission administers the rule. It applies to covered operators of child-directed websites and online services, and to covered operators with actual knowledge that they collect personal information from a child under 13.

COPPA is principally about children's personal information, not a universal determination of who may hold a social-media account. Its requirements include notices, parental consent where required, parental rights and protections for the information collected. Meeting a state account condition does not, by itself, complete that federal analysis.

The reverse is also true. Obtaining COPPA consent does not automatically authorize an account that a state provision prohibits. Nor does it establish that a parental-consent mechanism satisfies every separate state requirement.

Age assurance and parental consent answer different questions

Age assurance concerns the user's age. Verifiable parental consent concerns authorization from the child's parent. A result from an age check does not automatically establish who can consent for a child, and a child's own checkbox does not establish parental authorization.

The FTC's parental consent explanation describes an email to a parent coupled with additional assurance steps for information collected for internal use only. It also describes more reliable methods for uses involving disclosure to the public or third parties, including a returned print-and-send form, a credit card transaction, or a toll-free telephone number staffed by trained personnel.

The limited email approach is not blanket approval for emailing a parent and accepting any reply. The information use matters, and the mechanism needs to fit the applicable consent requirements. For an implementation review, use 16 CFR § 312.5 rather than a generic vendor claim that a flow is “parent verified.”

Map the information before choosing the mechanism

List the information the app collects, why it collects it, and who receives it. Include information collected through embedded services, not just fields visible on the signup screen. Then identify which collection and disclosure activities the proposed consent covers.

A consent record should be understandable to the people maintaining the app. If the team cannot tell what information use a parent authorized, the record is not a dependable product specification. Treat the federal and state permission questions as distinct even when they share interface components.

Turn the legal distinctions into a product brief

A shared technical component can support several legal workflows without making their rules identical. The useful design is a common set of capabilities with separate, reviewed decision logic. Avoid a single setting called “minor consent required” that silently mixes eligibility, access and privacy decisions.

The following four components are a planning structure, not a declaration that implementing them satisfies every applicable law.

Age information and its meaning

Document what an age result actually represents. A stated birth date, an estimated age band and a verified adult result are different forms of information. Do not label them all “verified age” if the underlying process supports different conclusions.

Record where the result is used: account eligibility, access to a feature, consent routing or another reviewed purpose. The same result may be useful in more than one place, but each use still needs a defined decision rule.

Do not invent an escalation threshold merely because a diagram needs another branch. If the team proposes additional checks, explain the uncertainty they address and obtain approval for the resulting data collection and user treatment.

Permission and account decisions

Separate the account decision from the permission record. An account might be ineligible, awaiting permission, or eligible without the particular permission under review. Those states should not be represented by a single Boolean value.

For each permission flow, specify who is authorizing what and which legal requirement the flow is intended to support. Record the version of the notice presented to that person. Also define what happens when the authorization is withdrawn or cannot be established.

A reusable consent service can be valuable, but reuse should preserve these distinctions. Do not assume that a consent obtained for one purpose authorizes every other activity associated with the account.

Data handling and lifecycle

Identify the information collected by the age and consent processes themselves. An age-check integration can introduce a separate data path, so review what the app and any outside service receive and retain. Request only information that the approved process needs.

Define retention and deletion behavior for the different record types. An age result, a supporting document and a consent record need not have the same lifecycle. Avoid keeping additional identity material solely because the integration makes it easy to store.

Support and corrections

Provide an understandable route for a user to question an incorrect age or account decision. Give support staff enough information to explain the result without exposing unnecessary identity data. Specify who can approve a correction and how the corrected result reaches the systems that use it.

This is a practical response to age restrictions risks, not a claim that an appeal route cures a statutory violation. A correction process should fix the relevant decision rather than bypass an otherwise applicable restriction.

Keep a handoff record, not an invented enforcement checklist

A useful internal record connects a legal conclusion to a product behavior. It should let a new engineer, lawyer or support lead understand why the behavior exists and what assumptions it depends on. That is different from claiming to know what an attorney general will demand in a particular investigation.

Use a requirements record with fields such as:

These are recommended working records, not a prescribed response to a civil investigative demand. The contents of an actual demand must be assessed on their own terms. Documentation also does not guarantee that a regulator will accept a method or decline enforcement.

Avoid unsupported penalty calculations in this record. A quoted per-violation maximum is not a formula establishing what counts as a violation, how violations are counted, or what a court would award. Do not multiply it by accounts, days or sessions without a legal basis for that calculation.

Keep decisions traceable when requirements change. If a permission flow is replaced, preserve enough context to understand which version governed an earlier account decision, while applying the approved retention rules to the underlying personal information.

Test whether the build has borrowed the wrong law

Before release, test the distinctions as well as the happy path. The goal is to find places where a shared component has quietly imported a rule from the wrong statute. Use the approved legal requirements as the expected results—not assumptions carried over from another state's design.

Include these questions in the review:

An app can share infrastructure across these reviews. What it cannot safely share is an unexamined legal conclusion. Keep Florida's account framework, Texas's SCOPE Act duties, Texas's sexual-content access law and COPPA's privacy requirements distinct until the legal and product teams have connected each applicable provision to a specific behavior.

That is the useful starting point for app compliance: identify the right law, preserve the difference between eligibility and permission, and build only from requirements that have actually been approved for the service.