A checkout field is a question you are asking a stranger who is standing up, holding a phone in one hand and a card in the other, and who has already decided to give you money. Every question is a chance for them to stop.
That does not make all fields equal. Some are load-bearing: the courier cannot deliver without them, or the payment will not clear. Some exist because somebody wanted the data once and nobody has revisited it since. And a few are worth their friction because they prevent a failed delivery or a chargeback.
So the useful exercise is not shortening the form for its own sake. It is going through the form field by field and asking what each one does for this order. If the answer is that it helps the parcel arrive or the payment succeed, keep it. If the answer is that marketing might want it later, it belongs after the thank-you page, not before it. This is the order we work through them in, roughly from most expensive to least.
Forced account creation costs the most, so remove it first
Asking someone to create an account before they can pay is the single most expensive question in most checkouts. It arrives at the worst moment, it asks for a decision unrelated to the purchase, and it introduces a password, which is where people go to find a different store.
Guest checkout should be the default path and it should be the obvious one. If your platform offers both, check what a new visitor sees first on a phone. It is common to find guest checkout present but positioned below a login form, which means the first thing a first-time buyer reads is a request for credentials they do not have.
The usual objection is that accounts drive repeat purchases. They do not, on their own. An account created under duress at checkout is a password nobody remembers. The path that works is to take the order as a guest, then offer to save the details after payment, when the customer has their order number, their confidence and no reason to leave.
If you sell to businesses and need approved accounts, that is a real constraint. Handle it with a separate flow for trade buyers rather than by putting the barrier in front of everyone.
Every field you keep should be able to explain which failure it prevents.
Then cut the fields the courier never reads
The next group is fields that exist in the form because the form template had them, not because anyone uses the data.
Company name is the usual offender for a consumer store. Most customers leave it blank, some pause to wonder whether it is required, and nobody downstream reads it. Title or salutation is another: it adds a dropdown and buys nothing. Address line two is more subtle, since apartment and unit numbers matter, but it should be clearly optional and it should not sit between two required fields where it reads as mandatory.
Phone number is the one to think about rather than delete on principle. Some carriers genuinely use it for delivery notifications and failed-delivery contact, and for large or scheduled items it prevents expensive missed deliveries. If your carrier uses it, keep it and say why in the label. If nothing in your operation ever calls that number, it is a field you are charging your customers to fill in.
The test for this group is simple: pull a month of orders and look at how often each optional field is filled in, then ask the person who ships the parcels whether they have ever looked at it.
Move the marketing questions to the thank-you page
How did you hear about us, date of birth, preferences, product interests, referral codes for programs the customer has not joined. These are all reasonable things to want. None of them belong in front of a payment.
The thank-you page is a better place for every one of them, and it usually gets a higher response rate, because the customer is relieved, finished and briefly willing to help. Ask one question there, not five. If you want attribution, how did you hear about us as a single question on the confirmation page is more honest data than the same question asked while someone is trying to pay.
Email marketing consent is the exception that has to sit inside checkout, because you need the address anyway and the consent has to be tied to a moment. Keep it as one unticked box with a plain description of what you will send. Do not pre-tick it, do not bury it in the terms, and do not use language that implies the order depends on it.
SMS consent is the same, with the added point that it needs its own separate opt-in, clearly worded, because consent for one channel is not consent for another.
Keep the fields that stop failed deliveries and failed payments
Shortening a checkout can cost more than it saves if you remove the parts that protect the order.
Address validation is worth its weight. A suggested-address prompt that catches a mistyped postcode prevents a parcel going to the wrong street, which is a refund, a reship and a support conversation. Done well it also shortens the form, because autocomplete fills four fields from a few keystrokes.
Billing address matters where your payment processor or fraud rules use it. If your provider requires it for verification on card payments, removing it raises declines, which look like conversion problems and are actually payment problems.
For anything age-restricted, regulated, heavy or delivered by appointment, the extra questions are the cost of doing business and should be presented as such, early, with an explanation. Customers accept friction they understand.
The rule is that a field earns its place by protecting the order. If you cannot say which failure it prevents, it is not protecting anything.
A field you keep should still cost the customer less
Removing fields is only half the work. The fields that stay can be made much cheaper to complete, and this is where a lot of quiet conversion sits.
Use the right keyboard for each input, so a numeric pad appears for the postcode and phone number instead of a full alphabetic keyboard. Set the autocomplete attributes properly so the browser and the phone can fill name, address, email and card details in one tap. Turn off autocapitalise and autocorrect on email fields, because autocorrect quietly breaks addresses and the customer gets blamed for it.
Label fields above the input rather than inside it, so the label does not disappear when someone starts typing and cannot check what they entered. Validate as they go and write error messages that say what to do, not that something is invalid.
And check the whole thing on a real phone, ideally an older one on a slow connection. Test it one-handed, standing up. A checkout that is comfortable on a desktop with a mouse can be close to unusable on the device most of your customers are holding.
Change one thing, then measure the step it belongs to
Checkout changes get made in batches and then nobody can say what worked. Do them one at a time and watch the step that field lives on.
The numbers to hold are completion rate from cart to checkout, from checkout to payment, and from payment to order, split by mobile and desktop. Those three splits tell you where a change landed. A store-wide conversion number moves too slowly and mixes in traffic changes that have nothing to do with the form.
If you have enough traffic for a test to mean anything, test. If you do not, make the change, note the date, and compare a fortnight before with a fortnight after, on the same traffic sources. Comparing a promotional week against a quiet one will tell you nothing.
Watch support tickets as well. If removing the phone number produces a run of failed deliveries, that shows up in the inbox before it shows up anywhere else, and it is a good reason to put a field back.
Most stores find that the first two changes on this list are worth more than everything else combined, and both of them are settings rather than code.