Field-Level Security (FLS) is set per profile or permission set. For each field on each object you set Read, Edit, or Hidden. FLS controls API-level access too — even if a hidden field is on a page layout, the user simply doesn't see it. FLS also affects what's visible in reports, list views, search results, and to integrations using that user's credentials.
Page Layout is set per object and (optionally) per record type. The layout controls whether a field appears on the detail page and how it's grouped — but only for users with FLS access to that field. If FLS hides a field, no page layout will show it.
So FLS is the gate; the page layout is the placement. FLS wins when the two conflict.
Practical implication: if you want a field to be invisible to a group of users and not exposed via the API, set its FLS to Hidden for those profiles/permission sets. If you only want it off the screen but accessible programmatically (rare but it happens), remove it from the page layout but keep FLS Read or Edit.
Lightning Record Pages with Dynamic Forms add a wrinkle: with Dynamic Forms, the page layout's field section is replaced by component-level field placement, but FLS still gates everything. Dynamic Forms do not change the FLS rule — they just give finer control over placement and conditional visibility.