IEEE Access Submission Guide: Requirements, Formatting and What Editors Want

This page is about package readiness, not post-upload workflow.

Use it when you are still deciding whether:

• the selected article type actually matches the manuscript
• the baselines, literature comparison, and validation are strong enough
• the reproducibility case is visible enough for IEEE Access editors
• the package is stable enough to survive the first technical screen

If you want the upload flow, review routing, and where the process slows after submission, that belongs on the submission-process page.

• Main article types: Research Article, Topical Review, Theory, Survey, Perspective, Applied Research, Negative Result, Methods, Tutorial, Standards, Comment, Reply, Debate, Exposition, Meta-Analysis, Unsolved Problem
• Page limits: IEEE Access states it does not have a general page limit
• Readability rule: IEEE Access strongly recommends staying under 20 pages; over-20-page papers generally need a pre-submission inquiry unless they are Surveys or Topical Reviews
• Exception: Comment articles are capped at 2 pages unless the Editor-in-Chief approves more
• Figures and supplements: Extra technical detail, code, and data links are strongly encouraged when they support reproducibility
• Template: Use the IEEE article template and keep the article type consistent with the content
• Peer review: All article types undergo the same rigorous peer review
• Reproducibility: Code and data sharing are encouraged, with post-publication reproducibility badges available

One thing IEEE Access does unusually well is article-type definition. It doesn't just publish standard research papers. It also accepts Surveys, Tutorials, Methods papers, Negative Results, Perspectives, Standards articles, Debate papers, Meta-Analyses, and Unsolved Problems.

That flexibility helps only if you pick the right type. A survey that reads like a casual narrative review should not be labeled a Survey. IEEE Access says a Survey should use a clear framework for selecting and excluding papers and should draw an overall conclusion from the body of literature.

The journal also says it has no general page limit. That's useful, but dangerous. Some authors take it as permission to submit a 40-page manuscript with no editing. Bad idea. Editors still want proportion. Long papers need a reason to be long.

The only explicit cap in the author guidance is for Comment articles, which have a maximum length of 2 pages unless the Editor-in-Chief approves more.

The author guidance also adds an operational constraint many people miss: if you want to go beyond 20 pages, IEEE Access expects a pre-submission inquiry to the EIC unless the paper is a Survey or Topical Review. So "no page limit" is real, but it is not permission to submit an unedited long draft.

Before the formal submission starts, the package should already contain:

• a clearly chosen article type that matches the real manuscript identity
• baselines and literature comparison strong enough to survive reviewer skepticism
• a reproducibility story that is more than an afterthought
• figures, methods, and claims that all support the same technical contribution
• short biographies for all authors already prepared for inclusion in the manuscript
• a cover letter that explains why IEEE Access is the right home

When those pieces are still shifting, the problem is not the portal. It is that the package is not ready for IEEE Access yet.

Your cover letter should explain why the chosen article type is correct. That's more important here than at many journals.

If you call the paper a Tutorial, say who the intended reader is and what prerequisite background they need. If you call it a Perspective, explain the big-picture uncertainty or disagreement it addresses. If you call it Applied Research, make clear what practical problem is solved and what quantitative validation supports it.

Don't rely on the journal's broad scope to do the work for you. IEEE Access is broad, but editors still need a reason to send the paper to review instead of deciding the framing is off.

IEEE Access is unusually explicit about what it checks before review. The submission guidance says:

• all authors must appear in both the source file and manuscript PDF
• short biographies are required for all authors
• poor grammar can trigger immediate rejection
• retracted references can trigger return or rejection
• keywords should be accurate enough to help match the paper to the right Associate Editor
• opposed reviewers can be listed if needed

That matters because IEEE Access is fast partly by being strict up front. If the package is sloppy, the journal does not want to spend weeks discovering that later.

Article-type mismatch. A descriptive overview labeled as a Survey or a practical systems paper framed as Theory creates friction before review even begins.

Weak validation. IEEE Access is not an elite-novelty journal, but it still expects credible proof. Thin baselines or incomplete experiments hurt quickly.

Reproducibility treated like a side note. If the code, data, or implementation logic are too vague to trust, the package looks weaker on first read.

Broad scope used as a substitute for fit. Editors still need to understand why this paper belongs in IEEE Access specifically, not just somewhere under the IEEE umbrella.

The biggest problem is article-type mismatch. A descriptive literature overview submitted as a Survey, or a practical systems paper submitted as Theory, creates friction before review even begins.

The second problem is lack of structure. Because IEEE Access permits long papers, authors sometimes forget that readers still need signposting. Use clear sectioning, tight captions, explicit problem statements, and conclusions that summarize technical contribution instead of repeating the introduction.

Also don't waste the title. The article type will appear in the published paper, so the title should focus on the technical contribution, not generic words like "A Study of" or "Research on."

IEEE Access puts real emphasis on reproducibility. The journal's reproducibility initiative encourages authors to share code, associated data, and documentation in repositories with persistent DOI and versioning, such as Code Ocean.

The journal also awards reproducibility badges, including Code Available and Code Reviewed. Those are post-publication, but the message for authors is clear: papers with transparent methods, shareable code, and documented outputs fit the journal better.

That program is technically post-publication, but it should change how you prepare the paper before submission. If the code, dataset construction, hardware assumptions, and output mapping are still too vague to package cleanly, the manuscript is not really IEEE Access-ready yet.

If you plan to share code, think beyond the upload. IEEE Access asks reproducibility artifacts to include hardware and software requirements, installation steps, expected outputs, input datasets, and an explanation of how reproduced outputs relate to the results in the paper. That's the standard editors want to see.

If you're targeting IEEE Access, a pre-submission check can help you confirm the right article type, tighten structure, and assess whether the data and code materials are complete enough to make the submission easier for editors to trust. A IEEE Access submission readiness check catches the technical and framing issues that generate quick editorial returns before you start the upload process.

In our pre-submission review work with manuscripts targeting IEEE Access, three patterns generate the most consistent desk rejections among the papers we analyze.

In our experience, roughly 35% of desk rejections at IEEE Access trace to scope or framing problems that prevent the paper from competing in this venue. In our experience, roughly 25% involve insufficient methodological rigor or missing validation evidence. In our experience, roughly 20% arise from a novelty claim that outpaces the supporting data.

• Article-type framing that does not match the manuscript's actual content. IEEE Access has 18 defined article types, each with distinct editorial expectations. We see a consistent failure where authors select "Survey" for a 30-paper literature overview that draws no synthesis conclusions, or "Theory" for a paper that presents experimental benchmarking rather than theoretical derivations. The submission guidance explicitly requires that Surveys use a clear inclusion/exclusion framework and draw an overall conclusion from the body of literature. Papers that do not meet the stated type criteria are returned at the editorial stage before peer review.

• Validation packages that treat baselines as optional. IEEE Access applies a sound-methodology model rather than a novelty threshold, but we observe that "sound methodology" is interpreted strictly at the validation level. Papers comparing a proposed method against only the authors' previous work, or against methods from 5+ years ago without justification, are rejected for insufficient comparison. We see this most often in signal processing and communications papers where recent SOTA methods are available in open repositories and reviewers expect them to be included.

• Reproducibility artifacts that cannot be independently verified. IEEE Access's reproducibility initiative encourages code and data sharing with DOI-linked repositories, hardware specifications, and expected output documentation. We see papers where the code link is a private GitHub repository or the dataset requires institutional access, making the reproducibility claim unverifiable. Reviewers flag this explicitly in their reports as a barrier to independent validation.

Verify format requirements against the journal's author guidelines before uploading.

SciRev author-reported data confirms IEEE Access's 21-day median to first decision. A IEEE Access article-type and validation check can verify whether your article-type framing, validation package, and reproducibility artifacts meet the editorial standard before you upload.

Before you upload, run your manuscript through an IEEE Access submission readiness check to catch the issues editors filter for on first read.