Acceptance Criteria Details

Enough detail for the work to be Ready. Is there enough detail to allow the Developers to estimate the work with confidence, for example, knowing it can be Done in a Sprint?

You can make them as detailed as they need to be.

I'd also say that not all of the details need to be known before work starts. For example, the Developers may know that there needs to be a first name form field and database going into the Sprint. They may find that, due to database limitations, the field is limited to 200 characters. They may add acceptance criteria during the course of the Sprint to capture information about behavior of the system at this maximum length - what happens, from a user's perspective, if 200 or 201 characters are entered into the form field. Some of the acceptance criteria may emerge about client-side versus server-side validation, error messages, and so on. Whether you formally capture these as "acceptance criteria" on the card or ticket or issue for work in your tool or perhaps just in automated tests or not at all is up to the team. The constraints and acceptable risk will guide a lot of these discussions.

Do we specify that it is a maximum of say 50 characters? If not then how do the developers know to do these things?

This is something about Technical Solution. This should be left to Developers. Not that to be added in AC, If the developers expect this much of spoon feeding from Product Owner, then the self management is missing. One of the Agile principles is the best architectures, requirements, and designs emerge from self-organizing teams.

So for the example you have given, the team should assess what could work well for users by applying their technical excellence. 

This is something about Technical Solution. This should be left to Developers. Not that to be added in AC, If the developers expect this much of spoon feeding from Product Owner, then the self management is missing. One of the Agile principles is the best architectures, requirements, and designs emerge from self-organizing teams.

So for the example you have given, the team should assess what could work well for users by applying their technical excellence.

Fully agree with this. Sufficient space must be left for command self-government. Excessive control and bureaucracy kill initiative and go against the principles of Agile product development

" And if we do specify it in the AC then it seems the AC can be really long for even some simple stories such as add a new user with for example 10 fields on the form."

User story represents conversation between PO and the dev team. Its a better approach when we write AC in ATDD/BDD format.

Example - we can use - Given-When-Then 

This will ensure to explain business expectation and this will guide Dev Team, QA ( in case of integration / System Test needed).

AC will represent all the condition, which must be fulfilled in order to mark a user story complete.

In case you have 10 fields - then something like below can help -

Given - 

10 fields in login form , Out of 10 fields these 5 fields must be populated with validation criteria (if any)

When - less than 5 mandatory fields were populated by user

Then - Error message to be thrown,  Here an elaborate error message can help business, Dev team and every other stakeholder involved.

Or a redirection on login page will done for incomplete 

When condition can include mandatory length of field, specific valid value for a field, as these are requirement from business, so its better to capture them in user story as a source of truth.