Four ways to do it, what each one costs, and where each one breaks.
Jira creates subtasks one at a time. If you have a checklist of eight things sitting in a meeting note, there is no box to paste it into. This page lays out the four routes people actually use, with the limits of each, so you can pick the cheapest one that fits how often you need it.
Short version: for a handful, use the built-in form. For a one-off migration of hundreds, use CSV import. For something that should happen automatically on a trigger, use an automation rule and budget the steps. For a list you paste by hand on a regular basis, the built-in options are all a poor fit, and that is the gap apps fill.
Open the work item, add a subtask, type a summary, save, repeat. Nothing to set up and nothing to pay for.
It is fine for three or four. It stops being fine at ten, because every subtask is a separate round trip through a form, and nothing is pasted - it is all retyped by hand from wherever the list already exists.
Jira's CSV importer can create parents and their children in one pass. Atlassian's documentation
sets out what the file needs: columns for Work item ID, Work type and
Parent, plus a Summary, and the rule that "the parent work items must appear before
their subtasks or child work items in the file". You also have to make sure the parent keys you
reference actually exist.
Two practical catches. First, you start the import from Jira administration - the documentation says to "log into your Jira Cloud site as a Jira administrator to start the import process", so this is not something most team members can run for themselves. Second, building the file is real work: for a one-off migration of several hundred items that effort pays for itself immediately, and for eight subtasks on a Tuesday afternoon it never does.
A rule can create subtasks when something happens - a transition, a new work item of a given type, a schedule. This is the right tool when the subtasks are predictable: the same checklist every time a release ticket is created, for example.
Two things to know before you design around it.
Automation is metered in steps, not in rules. Atlassian counts "a single executed part of an automation flow, including triggers, conditions, actions, branches, and loops" as one step, and the monthly allowance is pooled at the organisation level: 150 on Free, 400 per user on Standard, 750 per user on Premium, 1,000 per user on Enterprise. A rule that creates a parent plus five subtasks is not one step - it is the trigger, the create, and each child, every single time it fires. Dozens of such rules add up faster than people expect.
There is a separate service rate limit. It is not the same thing as your monthly allowance, which is why a rule can be throttled while your monthly usage sits at a fraction of a percent. Teams generating subtasks across hundreds of parents in one burst have reported Automation starting to fail partway through with a rate-limit error in the audit log. If you are doing something that large, spread it over time or batch it rather than firing it all at once.
The gap none of the above fills is the common one: a list that already exists somewhere, that you want to paste in now, on this work item, without writing a CSV or a rule. Several Marketplace apps cover it, free and paid.
Disclosure: I build one of them. Bulk Subtasks adds a panel to the work item, you paste one line per subtask, and it creates them - stripping bullets, numbering, checkbox markers, blank lines and duplicates first, because lists pasted out of notes and spreadsheets arrive with formatting attached. It is free with no user limit, runs entirely on Atlassian Forge, and stores nothing. It is capped at 50 subtasks per run, so it is not the answer for a several-hundred-item migration - that is still a CSV import job.